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Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://webapp.etsi.org/IPR/home.asp) . 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 

This Technical Specification (TS) has been produced by ETSI Technical Conmiittee Electromagnetic compatibility and 
Radio spectrum Matters (ERM). 

The present document is part 4 of a multi-part deliverable covering the Technical Requirements for Digital Mobile 
Radio (DMR), as identified below: 

Part 1 : "DMR Air Interface (AI) protocol" ; 

Part 2: "DMR voice and generic services and facilities"; 

Part 3 : "DMR data protocol" ; 

Part 4: "DMR trunking protocol". 
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Scope 



The present document contains technical requirements for Digital Mobile Radio (DMR) trunking systems operating in 
the existing licensed land mobile service frequency bands, as identified in CEPT/ERC/T/R 25-08 [10]. 

The present document describes the trunking services and facilities protocol of a scalable Digital Mobile Radio system, 
which covers three tiers of possible products: 

Tier I: DMR equipment having an integral antenna and working in Direct Mode (unit-to-unit) under a 

general authorization with no individual rights operation. 

Tier II: DMR systems operating under individual licences working in Direct Mode (unit-to-unit) or using a 

Base Station (BS) for repeating. 

Tier III: DMR trunking systems under individual licences operating with a controller function that 

automatically regulates the communications. 

NOTE: Tier II and Tier III products encompass both simulcast and non-simulcast systems. 

The DMR air interface complies with either EN 300 113-1 [1], EN 300 113-2 [2] or EN 300 390-1 [3], 

EN 300 390-2 [4], that has been specifically developed with the intention of being suitable for all identified product 

tiers. 

The DMR protocol is intended to be applicable to the land mobile service frequency bands, physical channel offset, 
duplex spacing, range assumptions and all other spectrum parameters without need for any change. 



2 References 

References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the 
reference document (including any amendments) applies. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http ://docbox . etsi . or g/Ref erence . 

NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee 
their long term validity. 

2.1 Normative references 

The following referenced documents are necessary for the application of the present document. 

[1] ETSI EN 300 113-1: "Electromagnetic compatibility and Radio spectrum Matters (ERM); Land 

mobile service; Radio equipment intended for the transmission of data (and/or speech) using 
constant or non-constant envelope modulation and having an antenna connector; Part 1 : Technical 
characteristics and methods of measurement" . 

[2] ETSI EN 300 113-2: "Electromagnetic compatibility and Radio spectrum Matters (ERM); Land 

mobile service; Radio equipment intended for the transmission of data (and/or speech) using 
constant or non-constant envelope modulation and having an antenna connector; 
Part 2: Harmonized EN covering essential requirements of article 3.2 of the R&TTE Directive". 

[3] ETSI EN 300 390-1: "Electromagnetic compatibility and Radio spectrum Matters (ERM); Land 

mobile service; Radio equipment intended for the transmission of data (and speech) and using an 
integral antenna; Part 1: Technical characteristics and test conditions". 

[4] ETSI EN 300 390-2: "Electromagnetic compatibility and Radio spectrum Matters (ERM); Land 

mobile service; Radio equipment intended for the transmission of data (and speech) and using an 
integral antenna; Part 2: Harmonized EN covering essential requirements under article 3.2 of the 
R&TTE Directive". 
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[5] ETSI TS 102 361-1: "Electromagnetic compatibility and Radio spectrum Matters (ERM); Digital 

Mobile Radio (DMR) Systems; Part 1: DMR Air Interface (AI) protocol". 

[6] ETSI TS 102 361-2: "Electromagnetic compatibility and Radio spectrum Matters (ERM); Digital 

Mobile Radio (DMR) Systems; Part 2: DMR voice and generic services and facilities". 

[7] ETSI TS 102 361-3: "Electromagnetic compatibility and Radio spectrum Matters (ERM); Digital 

Mobile Radio (DMR) Systems; Part 3: DMR data protocol". 

[8] lEC 61 162-1: "Maritime navigation and radiocommunications equipment and systems - Digital 

Interfaces - Part 1: Single talker and multiple listeners". 

[9] "The Unicode Standard" . 

NOTE: Available at: http://www.unicode.org/standard/standard.html . 

[10] CEPT/ERC/T/R 25-08: "Planning criteria and coordination of frequencies in the Land Mobile 

Service in the range 29.7-960 MHz". 

[11] ISO/IEC 646 (1991): "Information technology - ISO 7-bit coded character set for information 

interchange". 

[12] ISO/IEC 8859 series (1998 - 2001): "Information technology - 8-bit single-byte coded graphic 

character sets". 

2.2 Informative references 

The following referenced documents are not necessary for the application of the present document but they assist the 
user with regard to a particular subject area. 

Not applicable. 



3 Definitions, symbols and abbreviations 

3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply: 

l:l-mode: 1 payload channel mode 

NOTE: l:l-mode supports one "MS to fixed end" duplex call or one simplex call with an optional inbound 
Reverse Channel using a two frequency BS. 

2:l-mode: 2 payload channel mode 

NOTE: 2:1 -mode supports two independent calls which may be either "MS to fixed end" duplex calls or simplex 
calls using a two frequency BS. 

AlLUnit IDn: range of MS IDs to address all MS in a system (see TS 102 361-1 [5], annex A) 

Ambient Listening: optional form of voice call where the called MS answers then may enters a proprietary listening 
operation such as transmitting with the microphone mute open 

assigned channel: channel that has been allocated by the infrastructure to certain MSs using channel allocation 
command(s) addressed to those MSs 

NOTE: An assigned channel may be allocated for secondary control purposes or for a circuit mode call. 

asynchronous access: mode of operation whereby MS are permitted access to TS by employing the polite protocol 
defined in TS 102 361-2 [6] 

NOTE: In this mode MS are not required to listen to a TSCC to first determine their access rights. 



ETSI 



1 3 ETSI TS 1 02 361 -4 V1 .3.1 (201 0-06) 

Base Station (BS): fixed end equipment that is used to obtain DMR services 

bearer service: telecommunication service providing the capabiHty for information transfer between access points 

burst: elementary amount of bits within the physical channel 

NOTE 1 : The burst may include a guard time at the beginning and end of the burst used for power ramp-up and 
ramp-down. 

NOTE 2: Two bursts with different length are defined for DMR. A TDMA bursts which has a length of 30 ms and 
a Reverse Channel burst which has a length of 10 ms. 

NOTE 3: For detailed burst definition see TS 102 361-1 [5], clause 4.2.1. 

NOTE 4: A burst represents the physical content (channel) of a timeslot. 
call: complete sequence of related transactions between MSs 

NOTE: Transactions may be one or more bursts containing specific call related information. 

Caller Line Identity (CLI): ability to see who is calling you before answering the telephone 

channel: in the Time Division Multiple Access (TDMA) slot structure arrangement a channel comprises the pair of 
same numbered slots on the inbound and outbound duplex frequencies 

composite control channel: TSCC that may temporarily revert to a payload channel (if for instance the instantaneous 
traffic exceeds that which may be accommodated by the available payload channels) 

Control plane (C-plane): part of the DMR protocol stack dedicated to control and data services 

coverage area: geographical area within which the received signal strength from a radiating BS exceeds a specified 
threshold value 

dedicated control channel: TSCC that is continuously transmitted by a TS and never reverts to a payload channel 

Digital Mobile Radio (DMR): physical grouping that contains all of the mobile and/or fixed end equipment that is 
used to obtain DMR services 

direct mode: mode of operation where MSs may communicate outside the control of a network 

NOTE: This is conmiunication technique where any MS (MS) may communicate with one or more other MSs 
(MSs) without the need for any additional equipment (e.g. BS). 

downlink: process of transferring information in the outbound direction (TS to MS) 

duplex: mode of operation by which information can be transferred in both directions and where the two directions are 
independent 

NOTE: Duplex is also known as full duplex. 

extended address: source or destination that is not an MS address (such as a PABX extension, PSTN number or 
IP address) 

First In First Out (FIFO): storage type that retrieves information in the order in which it was stored 

fixed non- volatile storage: storage facility within a MS, the contents of which cannot be modified or added to by the 
operation of the MS or its user 

high-rate: Packet Data Transmission that uses dual slot data timing 

inbound: MS to BS transmission 

information element: subset (field) within a PDU 

intrinsic service: service which is inherent within a voice or data service 

NOTE: It forms an integral part of the signalling associated with that voice or data service. 
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item: MS payload transmission from the point at which the PTT is pressed to the PTT released 

line connected: call whereby one end of the call is connected to the radio system that does not use the DMR Air 
Interface 

NOTE: Examples may be connection to the PSTN or a PABX. 

logical channel: distinct data path between logical endpoints 

message trunking: mode of operation that a payload channel is permanently allocated for the complete duration of the 
call, which may include several separate PTT items (several PTT activations by separate terminals) 

NOTE: The channel is only de-allocated if the call is (explicitly) released or if a time-out expires. 

Mobile Station (MS): physical grouping that contains all of the mobile equipment that is used to obtain DMR mobile 
services 

multi-part call set-up: call set-up procedure whereby the full source and destination address cannot be accommodated 
in a single CSBK signalling block 

NOTE: The UDT procedure is invoked to transfer the address information using Multi Block Control (UDT) 

signalling. UDT is also invoked to transport supplementary_user data, user data and extended addressing 
between DMR entities. 

network personalization: configuration parameters appropriate to network configuration programmed into a MS that 
may be set by an external agency but not by the user of an MS 

non- volatile storage: readAVrite storage that stores information during operation of a MS that is protected from the 
effects of switching off the MS 

outbound: BS to MS transmission 

packet data: method for the transmission of information by which the information is transmitted as packets each 
containing a fragment of the total information to be transmitted 

PARtition (PAR): Information Element used to partition MSs on a TS that implements two control channels (TSCCs) 

payload: bits in the information field 

personalization: configuration parameters that may be set by an external agency but not by the user of an MS 

physical channel: TDM A burst 

NOTE: The DMR radio frequency channel contains two physical channels. 

polite protocol: "Listen Before Transmit" (LBT) protocol 

NOTE: This is a medium access protocol that implements a LBT function in order to ensure that the channel is 
free before transmitting. 

power-save-frame: sixteen time slots (480 ms) defining a period for sleeping MS to wake 

privacy: secret transformation 

NOTE: Any transformation of transmitted information that is derived from a shared secret between the sender and 
receiver. 

Protocol Data Unit (PDU): unit of information consisting of protocol control information (signalling) and possibly 
user data exchanged between peer protocol layer entities 

radio frequency channel: radio frequency carrier (RF carrier) 

NOTE: This is a specified portion of the RF spectrum. In DMR, the RF carrier separation is 12,5 kHz. The 
physical channel may be a single frequency or a duplex spaced pair of frequencies. 

random access attempt: period from the initiation of the random access procedure until the MS receives a response 
from the BS or abandons the procedure (e.g. after sending the maximum permitted number of retries) 
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Ready For Communications: MS state where the user has specifically indicated the readiness to communicate, e.g. the 
MS equivalent of a telephone off hook 

read write storage: storage facility within the MS the contents of which may be modified by the operation of the MS. 
The stored data is lost when the MS is switched off 

Received Signal Strength Indication (RSSI): root mean squared (rms) value of the signal received at the receiver 
antenna 

registration (MS view): network procedure whereby the MS asks for and the TSCC grants access to a particular MS. 

NOTE: The MS is required to inform the system whenever it enters a new registration area. 

revive: mechanism whereby DMR facilities available to a MS that has been stunned may be restored 

serving site: radio site that is currently proving service to the MS 

signalling: exchange of information specifically concerned with the establishment and control of connections, and with 
management, in a telecommunication network 

simplex: mode of working by which information can be transferred in both directions but not at the same time 

NOTE: Simplex is also known as half duplex. 

single-part call set-up: call set-up procedure whereby the full source and destination address is accommodated in a 
single CSBK signalling block 

site: totality of BSs and trunk site control equipment that processes calls in one location 

slot: See time-slot. 

stun: mechanism whereby DMR facilities available to a MS user may be denied 

superframe: 6 continuous TDMA bursts labelled "A" to "F" 

NOTE: A superframe has a length of 360 ms and is used for voice payload only. 
Supplementary Data Transfer Service: service to transfer supplementary data between DMR MS and MS/TS entities 
TDMA-frame: two continuous time-slots 
time-slot: elementary time unit for allocation of a burst 

NOTE: A timeslot has a length of 30 ms. 

transmission: transfer period of bursts containing information or signalling 

NOTE: The transmission may be continuous, i.e. multiple bursts transmission without ramp-up, ramp-down, or 
discontinuous, i.e. single burst transmission with ramp-up and ramp-down period. 

transmission trunking: mode of operation that a payload channel is individually allocated for each call transaction (for 
each activation of the PTT) 

NOTE: The channel is immediately de-allocated at the end of the call transaction (subject to unavoidable protocol 
delays). 

Trunked Station (TS): physical grouping that contains all of the fixed end equipment in one location that is used to 
obtain DMR Tier III services 

Trunk Station Control Channel (TSCC): control channel transmitted by the infrastructure to control the MS 
population 

TS Authorization: complete procedure whereby a MS tests the System Identity code and an optional step of 
authentication to ascertain if it is permitted to gain access 

Unified Data Transport: universal methodology used to transport data in DMR systems 

Uplink: process of transferring information in the inbound direction (MS to TS) 
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user plane (U-plane): part of the DMR protocol stack dedicated to user voice services 
vocoder socket: 216 bits vocoder payload 



3.2 Symbols 



For the purposes of the present document, the following symbols apply: 



Hz 

Nibble 
Octet 



absolute frequency 

4 bits grouped together 

8 bits grouped together, also called a byte 



3.3 



Abbreviations 



For the purposes of the present document, the following abbreviations apply: 



AI 


Air Interface 


ALS 


Ambient Listening Service 


BCD 


Binary Coded Decimal 


BER 


Bit Error Rate 


BS 


Base Station 


NOIF: 


A reference designating a fixed end device. 


CACH 


Common Announcement CHannel 


CC 


Colour Code 


CCL 


Call Control Layer 


CLI 


Caller Line Identity 


C-plane 


Control-plane 


CRC 


Cyclic Redundancy Checksum for data error detection 


CSBK 


Control Signalling BlocK 


CSBKO 


CSBK Opcode 


DLL 


Data Link Layer 


DMR 


Digital Mobile Radio 


DMRLA 


DMR Location Area 


EMB 


Embedded Signalling Field 


FEC 


Forward Error Correction 


FID 


Feature set ID 


FIFO 


First In First Out 


FLCO 


Full ink Control Opcode 


FOACSU 


Full Off Air Call Set-up 


ID 


IDentifier 


IP 


Internet Protocol 


LB 


Last Block 


LBT 


Listen Before Transmit 


LC 


Link Control 


MBC 


Multiple Block Control packets 


MS 


Mobile Station 


NOTE: 


A reference designating a mobile or portable radio. 


MSB 


Most Significant Bit 


MSC 


Message Sequence Chart 


NMEA 


National Maritime Electronic Asociation 


OACSU 


Off Air Call Set-up 


PABX 


Private Automatic Branch eXchange 


PAR 


PARtition 


PDU 


Protocol Data Unit 


PF 


Protect Flag 


PL 


Physical Layer 


PSTN 


Public Switched Telephone Network 
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PTT 

RC 

RF 

RFC 

RSSI 

SAP 



Push To Talk 

Reverse Channel 

Radio Frequency 

Ready For Communications 

Received Signal Strength Indication 

Service Access Point 



NOTE: Where a network provides a service. 

SDL Specification and Description Language 

SFID Standard FID 

SLCO Short LC Opcode 

SYNC SYNChronization 

TDM A Time Division Multiple Access 

TS Trunked Station 

TSCC Trunk Station Control Channel 

UAB UDT Appended Blocks 

UDT Unified Data Transport 

Unicode 16 bit character encoding 

U-plane User-plane 



Overview 



The present document describes a Digital Mobile Radio (DMR) protocol for Tier III trunked mobile radio systems that 
employ a Time Division Multiple Access (TDMA) technology with a 2-slot TDMA solution and RF carrier bandwidth 
of 12,5 kHz. 

Radio equipments (fixed, mobile or portable), which conform to the present document shall be interoperable with 
equipment from other manufacturers. Radio equipment of the present document shall also comply with 
TS 102 361-1 [5]. The payload voice channel procedures specified in clause 6.6.2 closely follow the procedures 
specified in TS 102 361-2 [6]. Similarly the packet data is transported on a payload channel described in clause 6.6.3 
follow the procedure specified in TS 102 361-3 [7]. Where differences exist those differences are stated in the payload 
channel clauses of the present document. 

Slot formats, field definitions, and timing are defined for MS/BS (TS/TSCC) control signalling. The standard can be 
used to implement a wide variety of systems, from small systems with only a few physical radio channels (even single 
physical radio channel systems), through to large networks, which may be formed by the interconnection of BS radio 
sites. 

A description of the TDMA structure is provided followed by the basic slot formats and bit definitions appropriate to 
the trunking protocol. Where procedures are common to the Service and Facilities defined in TS 102 361-2 [6] and 
TS 102 361-3 [7], only the differences are described in the present document. 

The present document does not provide the specification or operational detail for system implementation that include 
but are not limited to network management, vocoder, security, data, subsystems interfaces and data between private and 
public switched telephone networks. It describes only the appropriate access requirements compatible with the Air 
Interface. 

The protocol offers a broad range of user facilities and system options. However, it is not necessary to implement any or 
all of the facilities available; an appropriate subset of the protocol could be implemented, according to the user 
requirements. Also, there is scope for customization for special requirements, and provision has been made for further 
standardized facilities to be added to the protocol in the future. 

The standard defines only the over-air signalling and imposes only minimum constraints on system design. 

Trunked radio systems are characterized by regulating channel access. A logical channel is assigned as a control 
channel (TSCC). The TSCC has an Inbound path for transmissions from MSs (inbound and outbound path for 
transmissions from the Trunked Station (TS) to MSs (outbound channel). Control channel packets generated by a Trunk 
Station Control Channel (TSCC) transmit on the outbound path that all MSs listen to when not involved in a call. MSs 
request access to the system by random access. The system resources are then granted by the Trunk Station Control 
Channel (TSCC). This trunking protocol is designed to minimize the signalling required to provide MSs with a 
particular service in order to provide the greatest possible throughput. 
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Trunked radio systems may be characterized by the following possible configurations: 

a) Dedicated Control Channel: 

A Trunk Station Control Channel (TSCC) is transmitted continuously. This channel occupies one DMR 
TDMA channel. MS access is strictly controlled and access is by invitation only. One TSCC can support 
a large number of payload channels. There are a number of Tier III services (such as short data 
messaging) that only utilize the TSCC. This mode of operation yields the highest performance and 
throughput. 

b) Composite Control Channel: 

A Trunk Station Control Channel (TSCC) may revert to a payload channel if a payload services is 
requested and no other payload channels are available. When the payload call is completed, the channel 
returns to its control channel function. The ability to have composite control channels is of benefit for TS 
with a very small number of physical radio channels. When the TSCC reverts to a payload function. MS 
who remain idle lose the control channel and cannot access the system and its services until the control 
channel returns. Thus the throughput and performance must be assessed and balanced with the benefits 
of the additional temporary payload channel. The present document does not specify if a TSCC shall 
continuously transmit slots inviting access. 

c) "Time Share" Control Channel: 

The term "time-shared control channel" refers to a control channel where multiple TS (whether co-sited 
or multi-sited) share one physical radio channel for control purposes by dividing the use of the frequency 
in time, (not to be confused by DMR TDMA). Each TS transmits a burst of control channel activity in 
turn. This mode of operation is complicated in DMR systems because each physical channel is able to 
support two independent TDMA logical channels. The present document does not attempt to solve the 
difficulty. ETSI-DMR does not support time-share control channels. 

d) Asynchronous Access: 

In some radio spectrum, independent users/agencies share frequencies and national administrations 
mandate that when not transporting payload, the TS must de-key and yield use of the channel(s) to the 
co-channel users (i.e. by default, the equipment is de-keyed). Also, there can be no interconnection 
between the independent users/agencies because, they are independent and may not even be co-located at 
a site (independent users/agencies may not wish to coordinate use of the channel). Additionally, some 
co-channel users may just be conventional talk-around users, in which case there is no fixed end 
equipment to coordinate. What may be practical in this scenario is to trade-off (or sacrifice) control 
channel capacity/performance for the ability to support trunking. The present document provides the 
facility for MS to activate a physical TSCC channel whereupon a short burst will regulate and invite 
access. 

4.1 Protocol architecture 

The purpose of this clause is to provide a model where the different functions and processes are identified and allocated 
to different layers in the DMR protocol stack. 

The protocol stack in this clause and all other related clauses describe and specify the interfaces, but these stacks do not 
imply or restrict any implementation. 

The DMR protocol architecture that is defined herein follows the generic layered structure, which is accepted for 
reference description and specification of layered communication architectures. 

The DMR standard defines the protocols for the following three-layered model as illustrated in figure 4.1. 

The base of the protocol stack is the Physical Layer (PL), which is the layer 1. 

The Data Link Layer (DLL), which is the layer 2, shall handle sharing of the medium by a number of users. At the 
DLL, the protocol stack shall be divided vertically into two parts, the User plane (U-plane), for transporting information 
without addressing capability (e.g. voice or data stream), and the Control plane (C-plane) for signalling with addressing 
capability, as illustrated by figure 4.1. 
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The Call Control Layer (CCL), which is layer 3, lies in the C-plane and is responsible for control of the call (addressing, 
facilities), provides the services supported by DMR, and supports the Data Service. U-plane access at layer 2 (DLL) 
supports voice and packet data service, which is available in DMR. The Control Layer and the facilities and services 
offered by Tier III DMR are described in the present document. 




Layer 1 



Control Plane 
Call Control Information 



Intrinsic Services 



Short Data Service 
Packet Data Service 



V V V V 

CALL CONTROL LAYER 



DATA LINK LAYER 



User Plane 



Voice Pay load 



PHYSICAL LAYER 



Figure 4.1 : DMR protocol stack 



4.1 .1 Air Interface Physical Layer (layer 1) 

The Air Interface layer 1 shall be the physical interface. It shall deal with the physical burst, composed of bits, which is 
to be sent and/or received. The Physical Layer is described in parti of this multi-part deliverable, see TS 102 361-1 [5]. 

The Air Interface layer 1 contains the following functions: 

modulation and demodulation; 

transmitter and receiver switching; 

RF characteristics; 

bits and symbol definition; 

frequency and symbol synchronization; 

burst building. 

4.1 .2 Air Interface Data Link Layer (layer 2) 

The Air Interface layer 2 handles logical connections and hides the physical medium from the upper layers. The Data 
Link Layer is described in clauses 5 to 9 of TS 102 361-1 [5]. Layer 2 services are described in the present document if 
those services are not already described in TS 102 361-1 [5]. 

The main functions are as follows: 

• channel coding (FEC, CRC); 

• interleaving, de-interleaving and bit ordering; 

• service answer response and retry mechanism; 
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media access control and channel management; 

framing, superframe building and synchronization; 

burst and parameter definition; 

link addressing (source and/or destination); 

interfacing of voice applications (vocoder data) with the PL; 

data bearer services; 

exchanging signalling and/or user data with the CCL; 

authentication by challenge and response. 

4.1 .3 Air Interface Call Control Layer (layer 3) 

Air Interface layer 3 (CCL) is applicable only to the C-plane, and shall be an entity for the services and facilities 
supported by DMR on top of the layer 2 functionality. The Call Control Layer for trunking described in the present 
document and may have embedded intrinsic services associated to it. 

The CCL provides the following functions: 

BS/TS/TSCC activation / deactivation (for asynchronous access mode); 

establishing, maintaining and terminating of calls; 

individual or talkgroup call transmission and reception; 

destination addressing (DMR IDs or gateways as appropriate); 

support of intrinsic services (emergency signalling, pre-emption, late entry, etc.); 

data call control; 

announcement signalling; 

management of available resources: 

management of a control channel resource by a random access protocol; 

queuing for payload resource; 
individual or talkgroup call set-up via a dedicated signalling channel; 
MS location information by registration; 
MS power save; 
broadcast of system parameters to radio subscriber terminals. 



ETSI 



21 ETSI TS 1 02 361 -4 VI .3.1 (201 0-06) 



4.2 Services and Facilities 



A Tier III system is able to support either a wide range or narrow range of Services and Facilities. Users who select a 
service specified in the present document that is not supported by a particular system shall receive an unambiguous 
refusal of service response. 

The services and facilities defined in the present document may be used for Tier III products and is called the "default 
feature set" which is allocated to the "Standards Feature ID (SFID)". There is a possibility in the DMR standard which 
allows manufacturers to define and implement "private" feature sets which contain additional "private" services and 
facilities, which may possibly not be understood by products not supporting this "private" feature set. In addition, some 
"Standards Feature ID" PDUs may contain optional manufacturer specific information elements. 

The "standard feature set" contains the following services and facilities: 

a) Generic services: 

1) MS Access control and management using a control channel and a random access protocol; 

2) MS Location within the system radio coverage by radio site identification and registration; 

3) Control Channel hunting; 

4) System acquisition authorization; 

5) A Unified Data Transport mechanism to support the short data service, the supplementary_user data 
service and extended_addresses through gateways; 

6) Broadcast of system parameters to MS; 

7) MS Authentication; 

8) Feature Not Supported; 

9) MS dynamic power control; 

10) MS Pre-emption control. 

b) Primary voice services: 

1) talkgroup call service; 

2) individual call service. 

c) Secondary voice services: 

1) all_MS call service; 

2) broadcast voice call service; 

3) open voice channel mode call service. 

d) Primary Data Services: 

1) Short Data Service; 

2) Packet Data Service. 

e) Supplementary Service: 

1) Supplementary_user data transfer service; 

2) MS stun and revive; 
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3) MS Kill; 

4) Answer Call Service; 

5) Cancel Call Service. 

The description of the services and features use diagrams where necessary to illustrate and highlight specific points both 
on the control channel and pay load channel. 

4.3 Device Addresses 

4.3.1 MS Addresses 

Tier I and Tier II MSs shall be personalized with at least one individual or one talkgroup identity (TS 102 361-2 [6], 
clause C.2.2). Tier III MSs shall be personalized with at least one individual identity and may be a member of one or 
more talkgroups. 

NOTE: MS individual addresses and talkgroups occupy separate address space (see TS 102 361-1 [5]. annex A. 
Thus it is possible that a talkgroup may have the same numeric address value as an individual MS 
numeric address value. There is no ambiguity because the individual and talkgroup call services are 
separately identified in all PDUs where a particular address information element may carry either an MS 
ID or talkgroup. 

This protocol is able to make use of the user and number dialling plan described in TS 102 361-2 [6] DMR voice and 
generic services and facilities annex C. 

4.3.2 Services and Gateway Addresses 

The Tier III protocol defines additional addresses to identify Services and Gateways in PDUs exchanged between MS 
and TS (TS 102 361-1 [5], annex A). The addresses prescribed for Tier III systems are defined in clause A.4. 

4.4 Conventional/Trunked Systems 

Conventional Tier I and Tier II DMR systems permit MS to control their own channel access (subject to any polite 
protocol). 

Many of the conventional operations such as selection of the physical radio channel is automated by this protocol: 

a) A single site trunked network is characterized by multiple MS communicating with a single location Trunked 
Station (TS); 

b) A wide area trunked network is characterized by multiple MS communicating with a multiplicity of Trunked 
Stations (TS). 

A TS shall be equipped with one or more physical channels. Each TS may be configured with one or two control 
channels (TSCCs). Where two TSCCs are configured, the TSCCs may be arranged in one physical channel or separate 
physical channels. The Tier III protocol can separate the population of MS fleets between multiple TSCCs so that there 
is effective load sharing. 

For a fully regulated system, at least one channel shall be configured as a Trunk Station Control Channel (TSCC) for 
MS management, signalling, and broadcast of system parameters. MS access is strictly controlled on the TSCC. 

An unregulated asynchronous system shall permit MS access subject to polite rules. 



ETSI 



23 ETSI TS 1 02 361 -4 V1 .3.1 (201 0-06) 



4.5 MS Location 

As MS travel around a wide area network they may be within range of a number of different Trunked Stations (TSs). 
Registration is a method by which the system can determine which radio site or group of radio sites MSs are located 
within a wide area network. This information avoids searching for MSs throughout the whole network, consequently 
reducing call set-up time and control channel loading. 

Registration may also be employed by a Single Site system to determine when MSs are active and able to receive calls. 

A secondary application of the registration process is that it enables power save parameters to be passed between MS 
and the system. 

If an MS is switched off or is subjected to a user selected change of network, the MS may attempt to de-register. The 
MS makes a de-registration random access to the TSCC on a "best endeavours" basis. If the procedure is not completed 
within a short time window (T_dereg) the process is abandoned. 

4.6 Tier III Services 

A DMR TS can allocate resources for a range of services including individual call, talkgroup call, line connected call, 
and a selection of data services. 

Calls to talkgroups may be restricted by the Network to a single radio site or connected to a multiplicity of radio sites. 
The particular sites involved in the call may be defined by the Network using manual configuration or automatic 
selection. 

Supplementary data may be sent between MS and the network during the call set-up phase using the Supplementary 
Data Transfer Service to poll for, or deliver additional information using a Unified Data Transport method. Examples 
include: 

a) the inbound transport of extended_addressing dialling digits for calls to the PSTN, PABX extensions or dotted 
addresses for IP gateways; 

b) the transport of MS location information using data collected from lEC 61 162-1 [8] compatible devices; 

c) the transport of any supplementary_user data; 

d) the outbound transport of CLI information for calls from PSTN, PABX LINE and dispatcher gateways to the 
called MS(s); 

e) the outbound transport of an IP address to called MS. 

4.6.1 MS initiating calls 

A MS may initiate a call to any of the following called parties: 

a) an individual MS; 

b) a line-connected terminal device including a PABX extension or PSTN destination; 

c) a talkgroup, or all MSs in the system. 

The system shall send a refusal of service response to any calls that request inappropriate Services and Facilities for a 
particular destination address. 

Some services may be addressed to the TS itself. 

During the call set-up phase, the TSCC may pass information back to the caller, to indicate the progress of the call. For 
example, it shall indicate the reason for any delays in call set-up or the reason for a call failure. 
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4.6.2 MS receiving calls 



A MS may receive calls from a MS or line connected terminal device (such a device may be a PABX extension or the 
PSTN). 

In addition, some PDUs may originate from the TS itself. 

A MS shall send an acknowledgement rejecting any individual call that request inappropriate or unsupported Services 
and Facilities. 

For a call from an MS, the calling address shall be supplied to the called unit. For a call from certain line connected 
gateways such as a PABX extension or from the PSTN, the protocol enables Source Address information to be carried 
to the MS. (An example is CLI information from a PABX extension or the PSTN.) 

Incoming calls may be addressed to the MS individually or to a talkgroup. 

A called MS may transmit different types of acknowledgements to a calling MS unit, depending on whether a user 
answers a call, whether a call enters a call stack or whether a voice message should be left. The acknowledgements can 
be used by a calling radio to provide call progress indications, such as informative text and/or alerts, to the user of the 
calling MS. 

4.6.2.1 MS receiving individual calls 

A MS may refuse to accept all incoming calls, for example by means of a "will call-back" control, or incoming calls 
could be refused selectively, depending on the source of the call. If an MS user does not wish to proceed with an 
incoming call immediately, the user can indicate that the call will be returned. If a MS user does not wish to receive any 
incoming calls, the calls may be rejected completely. 

For voice calls, a system may employ two strategies as shown in clauses 4.6.2.1.1 and 4.6.2.1.2. 

4.6.2.1 .1 Off Air Call Set-Up (OACSU) 

The TS determines when the traffic channel is to be assigned. The assignment may be performed at any time after call 
establishment has been initiated in the TS. A traffic channel is allocated for the call whether or not the called party 
answers. 

4.6.2.1 .2 Full Off Air Call Set-Up (FOACSU) 

The traffic channel is only assigned when the called party user has specifically answered the call. When the called party 
has answered, the network initiates the traffic channel assignment in order to allocate a traffic channel to the MS. 

4.6.2.2 MS receiving calls to talkgroups 

A MS may be a member of an arbitrary number of talkgroups. 

An MS may be configured such that it may selectively accept or ignore a call to one if its talkgroup memberships An 
MS may also be configured to ignore a call to one of its talkgroup memberships if it is waiting for an individual call. 

4.6.2.3 MS receiving calls to AII_MS 

A number of IDs are reserved for the purpose of addressing every MS (all_MS) on a system. There are 16 All_Unit IDs 
(see TS 102 361-1 [5], annex A and TS 102 361-2 [6], annex C). Calls to all_MS are treated by the present document as 
broadcast calls to a talkgroup. 

4.7 Physical Link Organization 

This protocol makes use of the physical layer 1 prescribed in TS 102 361-1 [5] DMR Air Interface protocol. 
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4.7.1 Radio Frequency Allocation 

The Tier III protocol supports a number of different physical channel strategies to accommodate operation in radio 
channels that may be dedicated, in blocks or re-farmed. 

Physical radio channels may be specified by either: 

a) a logical channel plan whereby a transmitter and receiver frequency is mapped to a logical channel number. 
The Tier III protocol permits up to 4 094 such logical / physical relationships; and/or 

b) a mechanism whereby the absolute transmitter and receiver frequencies are specified in the PDUs that are 
passed between BS and MS at the air interface. 

4.7.2 Colour Code (CC) 

A Colour Code (CC) is present in the Embedded Signalling Field (EMB) and general data burst to provide a simple 
means of distinguishing overlapping sites, in order to detect co-channel interference. Tier III systems assign the 
physical channels automatically therefore the MS and TS must know and be in agreement which colour code is 
allocated for each physical channel. The following strategy is employed in Tier III systems: 

a) The default colour code is OOOO2. If a colour code has not been specifically assigned, or transmitted on the 
TSCC in an extended Channel Grant or extended Move PDU, the colour code shall be set to the default. 

b) In Tier III systems MS shall be polite to own colour code. 

c) MS may maintain a list of logical channel numbers and their corresponding colour code assignments 
(see annex C). 



4.8 



DMR TDMA burst and channel structure 



The described solution is based on the 2-slot TDMA structure described in TS 102 361-1 [5], clause 4.2. 
The logical channels are separated into two categories: 

• a control channel carrying signalling; and 

• payload channels carrying speech or data information. 

Generally MSs operate in half duplex mode using aligned channel timing (see TS 102 361-1 [5], clause 5.1.1) but full 
duplex is possible for calls to line connected terminals using Offset TDMA timing (see TS 102 361-1 [5], 
clause 5.1.1.2) by allowing a MS to transmit in one time slot and receive the fixed end transmission on the alternate 
time slot. MS that are directed to a physical channel using offset timing shall be notified by an identifier transmitted to 
the MS(s) during the call set-up. 

A generalized diagram of exchanges between the TSCC and MS is illustrated in figure 4.2 where the slots for the two 
TDMA physical channels are shown. 
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Key points particular to Tier III trunking illustrated by figure 4.2 include the following: 

• While the TSCC is keyed up, the two outbound logical channels are continuously transmitted, even if there is 
no information to send. If either of the logical channels is configured as a control channel, and that control 
channel is idle, information is constantly transmitted to manage MS access and broadcast parameters to MSs. 

• The channel 1 and 2 bursts in the inbound channel are offset 30 ms in time from the channel 1 and 2 bursts in 
the outbound channel. This number scheme allows a single channel identifier field in the outbound CACH to 
use the same channel number when referring to the inbound and outbound channels. 



• 



• 



• 



Differing SYNC patterns are used in voice bursts and data bursts to allow the receiver to differentiate between 
them. Different SYNC patterns are used for inbound and outbound channels to help the receiver reject 
co-channel interference. 

A physical channel that carries a TSCC shall use aligned timing as prescribed in clause 5.1.1.1 of 

TS 102 361-1 [5]. Two independent control channels or one control channel + one payload channel may be 

configured. A TSCC may temporarily revert to a payload channel. 

Referring to figure 4.2, a random access burst on the inbound channel labelled "A" shall be acknowledged by a 
PDU on the outbound channel. This acknowledgement may be transmitted in slot "B", although the protocol is 
able to postpone the acknowledgement to allow for computational or network delays. 

• For a MS response to a PDU received from the TSCC, the MS shall transmit its PDU in the timeslot but one 
following the end of the TSCC PDU. I.e. a PDU from the TSCC in slot "C" that requires a response from a MS 
shall be acknowledged on the TSCC in slot "D". 

• The MS response at "D" cannot collide with another random access burst because the slot is protected by 
setting the AT bit is the CACH to busy. MS must test this bit before making a random access attempt. Random 
access is not permitted if AT=1. 

• The outbound channel defines a CACH channel between TDMA bursts that manages the framing and channel 
access of the logical channels and provides a low speed channel for signalling. CACH framing bits are 
defined, allowing the low speed channel to support a range of PDU sizes. 

4.9 Introduction to the TS Structure 

These clauses outline some key aspects of the Tier III protocol by reference to examples. The Tier III protocol manages 
MS access and Service provision by means of a TSCC (control channel). MSs request Service by means of random 
access. The Tier III protocol provides a wide variety of configurations to match the requirements of dedicated and 
shared radio spectrum. The TSCC outbound channel may be: 

a) continuously transmitting slots that invite MS access, broadcast of system parameters to, and managing the 
resources that are available to MS; 

b) transmitting information as a) but reverting to a payload channel when other payload channels are not 
available; 

c) de-keyed until activated by an MS burst when used in shared spectrum. 
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4.9.1 An individual voice call example 



4.9.1.1 



Individual Call using OACSU 



Two MS, MS(A) and MS(B) are active listening to the TSCC. MS(A) requests a voice service to MS(B). Before a 
payload channel is assigned on the TSCC, the system checks that the MS(B) is in radio contact and wishes to accept the 
call. If MS(B) sends a positive acknowledgement response (indicating that MS(B) will accept the call), the system 
allocates a payload channel for the call. 
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Figure 4.3: Individual Call Set-up example using OACSU 

Referring to figure 4.3, some key aspects are described: 

a) TDMA Channel 2 is assigned as a TSCC. TDMA Channel 1 is idle. 

b) When a TSCC has no calls in progress, it will transmit system management or system broadcast PDUs to all 
MSs listening to the TSCC. MSs may listen to TDMA Channel 1 for the purposes of error rate measurement 
but they shall not make use of any information from those PDUs. 

c) MS(A) makes a Service Request at point "A" using aligned timing (see TS 102 361-1 [5], clause 5.1.1.1). 

d) The TSCC sends an AHOY PDU (point "B") addressed to MS(B) that requires an acknowledgement response. 

e) MS(B) responds with an acknowledgement at point "C". 

f) At point "D", the TSCC sends a Channel Grant PDU addressed to MS(A) and MS(B). A logical channel 
information element in the Channel Grant PDU directs the MSs to a particular physical and logical channel. 
The Channel Grant PDU is not acknowledged so the PDU is repeated for reliability at "E". A TSCC may 
transmit the repeated Channel Grant PDUs consecutively, or wait for a few slots before repeating the Channel 
Grant. 

g) In this particular example the TSCC has chosen to allocate the logical Channel 1 of this physical channel for 
the call. Logical Channel 1 therefore changes from idle to payload immediately after the TSCC transmits the 
first Channel Grant PDU. 

h) Since each TDMA burst takes 30 ms, the best case performance for a Tier III individual call set-up is 210 ms. 
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4.9.1.2 



Individual Call using FOACSU 



Two MS, MS(A) and MS(B) are active listening to the TSCC. MS(A) requests a voice service to MS(B). The TSCC 
checks that the MS(B) is in radio contact and wishes to accept the call. If MS(B) sends a positive acknowledgement, 
MS(B) alerts the user. Only when MS(B) answers the call doe the system a payload channel for the call. 
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Figure 4.4: Individual Call Set-up example using FOACSU 

Referring to figure 4.4, some key aspects are described: 

a) TDMA Channel 2 is assigned as a TSCC. TDMA Channel 1 is idle. 

MS(A) makes a Service Request at point "A" using aligned timing (see TS 102 361-1 [5], clause 5.1.1.1). 
The TSCC sends an AHOY PDU (point "B") addressed to MS(B) that requires an acknowledgement response. 
MS(B) responds with an acknowledgement at point "C". MS(B) alerts the user. 



b) 
c) 
d) 

e) 



The user actively answers the call at point "D" causing MS(B) to send a Answered Request to the TSCC, the 
TSCC sends a Channel Grant PDU addressed to MS(A) and MS(B). the alert generated at point "C" is 
cancelled. 

f) A logical channel information element in the Channel Grant PDU directs the MSs to a particular physical and 
logical channel. The Channel Grant PDU is not acknowledged so the PDU is repeated for reliability at "F". A 
TSCC may transmit the repeated Channel Grant PDUs consecutively, or wait for a few slots before repeating 
the Channel Grant. 

In this particular example the TSCC chooses a separate physical radio channel for the call. The particular physical and 
logical TDMA channel information elements are carried in the Channel Grant PDUs. The Channel Grant PDUs are 
repeated for reliability. 

4.9.2 A talkgroup call example 

For a talkgroup call, the intermediate step of checking if MS(B) is in radio contact is not required so the best case 
performance for a Tier III talkgroup call is 90 ms. 
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Figure 4.5: Talkgroup Call set-up example 

Figure 4.5 illustrates a call set-up for a talkgroup. MS(B) is a party to that talkgroup. For a talkgroup call, the 
intermediate step of checking if MS(B) is in radio contact is not required so the best case performance for a Tier III 
talkgroup call set-up is 90 ms. 

In this particular example the TSCC chooses a separate physical radio channel for the call. The particular physical and 
logical TDMA channel information elements are carried in the Channel Grant PDUs. The Channel Grant PDUs are 
repeated for reliability. 

Key protocol aspects are: 

a) When both payload channels are idle, no radio transmission is necessary. 

b) When at least one payload channel is assigned the transmitter is activated and one logical channel carries the 
payload for the call. The other logical channel remains idle. 

c) Although in this example the clocks and bursts in the payload channel are time aligned with the TSCC, there is 
no requirement to do so. 

4. 1 Network architecture 

The DMR trunked protocol is defined in terms of the Services and Facilities. It is defined to ensure interoperability with 
DMR MSs. The Tier III structure relies on the Air Interface TS 102 361-1 [5]. 

The gateways to Public Switched Telecommunication Network (PSTN), and other non Air-Interface gateways are not 
defined within the present document. They are shown only for informative purposes. 

A Trunked Station (TS) consists of one or more physical radio channels (BS), each physical channel supporting two 
TDMA logical channels. Either or both logical channels of a BS may carry a TSCC. All of the clocks of the BS making 
up a TS may be derived from a common reference standard so that the framing structure is synchronized across all BS 
within a TS. 

4.10.1 Network functions 

In addition to the normal call handling functions required to provide the telecommunication services identified above, a 
number of standard network procedures are needed for the efficient operation of the system and to provide an 
acceptable grade of service to the users. 
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4.10.1.1 Establishing service 



A notable feature of a Tier III trunked system is that physical channel acquisition is performed automatically when a 
MS is powered up. The user does not need to manually select physical channels. The relevant physical channel is stored 
in the MS or a search is performed to find an applicable TSCC. If the MS is directed to a payload physical channel on 
the TSCC, the applicable payload channel is transmitted to the MS by a Channel Grant PDU that specifies the physical 
and logical channel. 

4.10.1.2 Network Identifier 

All TS carry a network and radio site identifier. This identifier, the System Identity Code (C_S YScode) is transmitted 
frequently by a TSCC. The C_SYScode is carried in CSBK signalling packets and also embedded in the CACH. The 
C_S YScode is composed of MODEL, NET, SITE and PAR information elements. Within a particular network, the 
MODEL and NET remains a constant. Each TS is designated a different SITE parameter. MSs use the MODEL and 
NET to determine if they are authorized to attempt to become active on that network. 

4.10.2 MS Location by Registration 

The coverage area of a Tier III trunked network is divided into a number of Location Areas (DMRLAs). A DMRLA 
corresponds to a single radio site or a small number of radio sites structured as a DMRLAs. 

Implicit registration is the network functionality that registers the location of the MS without need for an explicit 
registration PDU. Implicit registration can be attained by any system PDU that conveys the MS individual identity, 
e.g. call request, service answer response. 

It is possible that due to adverse conditions the registration information held by the network and that held by the MS 
may not be the same. To restore and maintain the registration records: 

a) The system shall update its registration records from MS random access call requests (the network may 
however deny the service requested by the MS for other reasons). 

b) Responses from MS (resulting from a radio check for example) implicitly update the system registration 
records. 



4.11 Trunking methods 



DMR Tier III systems are able to implement the "message trunking", "transmission trunking" or "quasi-transmission" 
trunked methods. 

4.11 .1 Message trunking 

Message trunking is a payload channel allocation strategy in which the same payload channel is continuously allocated 
for the duration of a call, which may include several separate call items or transactions (i.e. PTT activation by separate 
terminals). The payload channel is only de-allocated when the call is explicitly cleared by the call owner in the case of a 
talkgroup call, either party hanging up during an individual call or if an activity timer expires. The BS may also clear 
the call at any time but the BS must be confident that all parties in the call hear the PDU to clear down the call. 

Once a payload channel has been allocated the users will experience the minimum delay for each transmission item 
since there is no queuing for the allocation of channel resources. The absence of any perceptible delay when the PTT is 
activated ensures that a conversation can proceed without interruption. This strategy is likely to minimize the processing 
and signalling overheads in the network infrastructure. 

The disadvantage of this strategy is that the channel remains allocated even when there may be significant gaps in the 
PTT items and this may result in less efficient use of the available channel capacity. 
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4.1 1 .2 Transmission trunking 

A payload channel is allocated for each PTT item. When the user releases the PTT, the payload channel is de-allocated 
down and the MS returns to the control channel. The following PTT is allocated a new payload channel. 

Users may experience a delay for each transmission item particularly when the system is busy because a payload 
channel may not be immediately available. In this case the system must queue the MS until a payload resource becomes 
available. An indication may be provided to the user that the payload channel is allocated for the speech item. 

4.11.3 Quasi-Transmission trunking 

A payload channel is allocated to the called and calling parties at the start of the call. When the user releases the PTT, a 
short hang-timer holds the payload channel to permit the other party to speak. If the hang-timer expires the payload 
channel is de-allocated and the next PTT item sets up a new call. This method overcomes the delay in transmission 
trunking but users experience different effects depending on the possible expiry of the hang-timer. 



Trunking Control Channel Formats 



A TS shall employ a minimum of one physical channel partitioned in time into TDMA frames and timeslots as defined 
in TS 102 361-1 [5], clause 4.2. At least one of the TDMA channels shall carry control channel signalling. When idle, 
MSs shall monitor the Trunk Station Control Channel (TSCC) outbound channel. This protocol permits one additional 
TSCC to be employed in a TS to share the load. 

The following SYNC patterns shall be deployed (see TS 102 361-1 [5], clause 9.1.1 for details and bit patterns for the 
frame SYNC): 



For the TS outbound channel 



BS sourced data. 



For the MS inbound channel 



MS sourced data. 



Signalling on the TSCC outbound channel is nominally continuous, with each TDMA Frame comprising two 
independent logical channels. The channel consists of two TDMA traffic channels (channels 1 and 2) as well as a 
CACH for channel numbering, channel access, system identification and power save. 
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Figure 5.1 : Slots and Frames 

Figure 5.1 illustrates slots, TDMA frames, random-access-frames and power-save-frames. 

A slot is the elementary DMR burst described in TS 102 361-1 [5]. 

A TDMA-frame encompasses two continuous time slots 1 and 2 or 2 and 1 . 

A power-save-frame is defined by transmission of four consecutive Short LC PDUs embedded in the CACH. A 
power-save-frame is transmitted by a TSCC every 480 ms. 
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5.1 



The use of the CACH 



The Short LC contains 3 octets of data associated with the SYS_Parms Short Link Control (Opcode - OOIO2) 
(see TS 102 361-1 [5], clause 7.1.4). Tier III systems that have any one of the logical channels configured as a TSCC 
shall continuously or periodically transmit the S YS_Parms Short Link Control to broadcast a sub-set of the System 
Identity Code, the Reg information element and a Common_Slot_Counter. All information carried by the Short Link 
Control is common to both logical channels. 

Since the entire Short LC payload can be delivered in 4 CACH bursts, one SLCO can be sent by the CACH every 
4x30ms= 120 ms. 

NOTE: The Tier III protocol makes use of the AT bit transmitted in the CACH as key elements in the random 
access protocol described in clause 6.2. 

5.1.1 SYS_Parnns - System Identity Code Subset 

The full C_Syscode information element is length 16 bits. Only the most significant 14 bits of the C_SYScode are 
carried in the CACH because the CACH is common to the two logical channels. One physical channel may carry one or 
two TSCCs. Each TSCC is identified by the two bit PAR information element that is conveyed in the two Least 
Significant Bits (LSBs) of the C_SYScode. 

The CACH is common to both logical channels so the PAR field cannot be specified in the CACH. Not all CSBKs on 
the outbound channel contain the SYScode. If a MS is searching for a control channel and trying to determine if it is 
permitted access, it may disregard a sampled channel by decoding the CACH. If there is no match then the MS does not 
need to stay looking for a CSBK that contains the C_Syscode. 

5.1.2 SYS_Parms - Reg 

The Reg information element carries a flag that specifies if this particular system requires MS to register before 
becoming active. The Reg is also carried in the Aloha CSBK PDU. 

5.1 .3 SYS_Parms - Common_Slot_Counter 

The Common_Slot_Counter is broadcast by the S YS_Parms and represents a positive integer in the range to 5 1 1 . The 
counter is incremented in each successive SYS_Parms Short Link Control PDU. When the counter is incremented from 
51 1 it rolls over to 0. The Common_Slot_Counter therefore increments every 120 ms. 
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Figure 5.2: Common Slot Counter 

Figure 5.2 shows how the Common Slot Counter is broadcast in the CACH. The Common_Slot_Counter is read by MS 
wishing to synchronize power save periodic sleep cycles (see clause 6.4.7). 
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5.2 Tier III signalling 



The Tier III protocol makes use of the single block CSBK and Multiple Block Control signalling packet structure 
described in TS 102 361-1 [5], clause 7.2. PDUs addressed to an individual MS or a talkgroup shall contain the Source 
Address. The Tier III protocol also uses the Unconfirmed Data type for the Unified Data Transport mechanism. UDT 
blocks consist of a header and a number of intermediate blocks contiguously transmitted. The UDT transmits the UDT 
header followed by one to four appended data (UDT intermediate blocks) to transport variable length system, user data 
or extended_addresses between entities. 

5.3 Modes of control channel 

TSCCs may be dedicated, composite or asynchronous. A dedicated TSCC never reverts to a payload channel whereas a 
composite TSCC may change its mode and carry payload if all other payload channels within a particular TS are busy. 

5.3.1 Dedicated TSCC 

A dedicated TSCC is generally employed in a TS where a large number of BS (hence payload channels) are employed. 
The advantages of a dedicated TSCC are: 

a) the TSCC is always available for MS who are hunting for a appropriate and valid service; 

b) the TSCC is always available to process secondary services such as MS location (registration), short data calls, 
etc.; 

c) the TSCC is always available to accept random access requests and queue such requests if resource is not 
immediately available; 

d) the TSCC can broadcast information to MSs more frequently as the TSCC function is not interrupted. 

5.3.2 Non-Dedicated TSCC 

A composite TSCC may suspend its control channel function and revert to a payload mode. This is suitable for TSs that 
are equipped with a very small number of payload channels and the traffic expected exceeds the capacity of those 
channels. The control channel reversion provides one additional payload resource. However, the shortcomings are: 

a) MS who are hunting for a appropriate and valid service may sample the physical channel when it has reverted 
to payload and therefore skip the channel; 

b) the TSCC is not available to process secondary services such as MS location (registration), short data calls, 
etc.; 

c) the TSCC cannot accept random access requests. The control channel interruption will most likely cause the 
MS not involved in the call to hunt; 

d) MS that return from a payload channel expecting the TSCC to be present will see a payload channel and 
therefore hunt for a new control channel. 



5.3.3 Operation in shared spectrum 



Clause 4 d) describes an asynchronous access. In this mode the TSCC remains inactive (in fact the physical channel 
remains de-keyed) until a MS activates the TSCC with a short burst. The MS then synchronizes to the forward control 
channel before making its random access service request. 
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5.4 



CSBK/MBC/UDT Block Structure 



CSBK/MBC/UDT PDUs may be sent by a TS on the outbound channel and MS on the inbound channel. In some 
instances it is necessary to send more information than can be accommodated in a single block CSBK PDU. In those 
cases multi-block PDUs of type MBC or UDT are transmitted. Multi-block PDUs shall use the following Data Type 
information elements (see TS 102 361-1 [5], clause 6.2): 

a) for PDUs except UDT, MBC Header and MBC Continuation are used; 

b) PDUs of type Data Header and Unconfirmed Data Continuation are used to transport information on the 
outbound channel and inbound channel for the Unified Data Transport (UDT) mechanism. 

5.4.1 CSBK/MBC/UDT PDUs on the TSCC outbound channel 

The PDUs sent by a TSCC on the outbound channel are classified as illustrated in figure 5.3. 
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C_ACK 



C_NACK 



C_WACK 



C_QACK 



Unified Data 
Transport 
Download 



short System Data 



Short Data I^Aessage 



Individual 



Talkgroup 



All Call 




iri 



CLI 



System l^essage \ 



Individual 



Talkgroup 



OVCM 



All Call 



Figure 5.3: TSCC CSBK/MBC/UDT Outbound channel Structure 
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Table 5.1 : TSCC CSBK/MBC/UDT Outbound channel PDUs 



Class 


Mnemonic 


PDU Descriptor 


Description 


Broadcast 


C GRANT 


Channel Grant 


Transfer a call to the payload channel 


C_MOVE 


Move to a new physical channel 


MSs shall move to an alternative 
TSCC 


C ALOHA 


Aloha 


To Manage Random Access 


C_BCAST 


Announcements 


PDUs intended for all MSs listening to 
this TSCC 


Ahoys 


C AHOY 


Ahoy 


Sent to MS and demand a response 


Acknowledgements 


C_xACKD 


Acknowledgements 


A response to PDUs from the MS that 
demand a response: 

C ACKD, C NACKD, 

C WACKD.C QACKD 


Unified Data 
Transport Outbound 


C_UDTHD 


Short System Message Outbound 
(see note) 


System PDU addressed to an 
individually addressed MS and 
demand a response 


Short Data Message Outbound 
(see note) 


Short data message addressed to an 
individual MS or talkgroup 


NOTE: C_UDTHD PDUs are made up of multiple blocks that consist of a UDT Header followed by 1 to 4 
appended UDT data blocks - see annex B. 



5.4.2 CSBK/MBC/UDT PDUs on the TSCC inbound channel 

The PDUs sent by a MS on the TSCC inbound channel are classified as illustrated in figure 5.4. 



SLOT 



Random Access 



Ackvitation 



Acknowledgements 



Unified Data 

Transport 

Upload 



Individual Serv 



Talkgroup Serw 



Secondary Serw 



Auth Challenge 



C_ACK 



C_NACK 



Auth Response 




Short System Data 



Short Data N[essage 



Uplink Ext Addr 



Uplink Dial Dig 



Uplink Data 



Individual 



Talkgroup 



All Call 



Figure 5.4: TSCC CSBK/MBC/UDT Inbound channel structure 
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Table 5.2: TSCC CSBK/MBC Inbound channel PDUs 



Class 


Mnemonic 


PDU Descriptor 


Description 


Random 
Access 


C_RAND 


Random Access 


Random Access Requests 


Ackvitation 


C_ACVIT 


Ackvitation 


A response to PDUs that invite a 
further response 


Acknowledgements 


C_xACKU 


Acknowledgements 


A response to PDUs from the TSCC 
that demand a response C ACKU, 
C NACKU 


Unified Data 
Transport Inbound 


C_UDTHU 


Short System Message Inbound 


System PDU addressed to an 
individually addressed MS or the 
TSCC as a response to an Ahoy PDU 
from the TSCC 


Short Data Message Inbound 


Short Data Message addressed to an 
individually addressed MS or the 
TSCC as a response to an Ahoy PDU 
from the TSCC 



5.4.3 CSBK/MBC PDUs on the Payload Channel Outbound channel 

The PDUs sent by a TSCC on the outbound channel are classified as illustrated in figure 5.5. 



CSBK 



P BCAST 



Channel ^rant 
(swap) 



P CLEAR 



P_PROTECT 



P AHOY 



MS Check 



Auth Challenge 



I Talkqroup Check 



P.ACK 
Acknow ledgements 



P_ACK 



P_NACK 



P_WACK 



P_QACK 



Individual 



Talkqroup 



All Call 




Figure 5.5: Payload CSBK Outbound channel Structure 
Table 5.3: Payload CSBK Outbound channel PDUs 



Class 


Mnemonic 


PDU Descriptor 


Description 


Broadcast 


P_GRANT 


Channel Grant (see note) 


Swap a call to a new payload 
channel 


P_CLEAR 


Payload Channel Clear 


Clear the call from the payload 
channel 


P PROTECT 


Channel Protection 


Access control 


Ahoys 


P AHOY 


Ahoy 


Sent to MS and demand a response 


Acknowledgements 


P_xACKD 


Acknowledgements 


A response to PDUs from the MS 
that demand a response P ACKD, 
P NACKD, P WACKD.P QACKD 


NOTE: A Channel Grant PDU is transmitted by the TS on a payload channel to swap an ongoing call to a new 
payload channel. 
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5.4.4 CSBK PDUs on the Payload Channel Inbound channel 

The PDUs sent by a MS on the Payload Channel inbound channel are classified as illustrated in figure 5.6. 



CSBK 



P_RANb 
Random Access 



Include 



P_ACK 

Acknowledgements 



H p_Aar 



P.NACK 



P_MAINT 
Maintenance 



Auth Response 



?_blSC 



Figure 5.6: Payload CSBK Inbound channel Structure 
Table 5.4: Payload CSBK Inbound channel PDUs 



Class 


Mnemonic 


PDU Descriptor 


Description 


Random 
Access 


P_RAND 


Random Access 


Random Access Requests 


Acknowledgements 


P_xACKU 


Acknowledgements 


A response to PDUs from the TS that 
demand a response P ACKU, 
P NACKU 


Maintenance 


P MAINT 


Call Maintenance PDUs 


Disconnect 



Trunking Procedures 



6.1 



Basic Structure 



6.1.1 Channel Structure 



6.1.1.1 



Fully Regulated Structure 



MS require a TSCC to regulate channel access. Therefore a TS shall incorporate one channel that is configured as a 
TSCC. A TS may support one additional TSCC within this protocol. 

The TSCC shall provide the following facilities: 

a) management and control of channel access by MS using a random backoff mechanism; 

b) processing service requests to and from MS and optionally to and from line connected entities; 

c) allocating payload resources to calls; 

d) broadcast of system information to MS; 

e) MS location management by registration; 

f) provision of services such as short data polling and transfer. 
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6.1 .1 .2 Shared Channel Unregulated Structure 

MS access the channel for services using the basic channel access rules prescribed in TS 102 361-1 [5], clause 5.2.1. 
MS shall be permitted to transmit asynchronous "BS activation" signalling to the TS in accordance with the "BS 
activation" feature (described in TS 102 361-2 [6]). On becoming activated, the TS shall commence transmitting TSCC 
activity on the outbound channel, and the MS shall derive slot timing from this activity. When activated, the TSCC shall 
transmit PDUs inviting random access. 

For Tier III, the outbound channel shall activate one TDMA channel as a TSCC and shall transmit Aloha and/or 
Broadcast PDUs in accordance with the random access procedures specified in the present document. 

The TS shall maintain the timer T_BS_Inactive for each active inbound channel. The T_BS_Inactive timer runs when 
there is no activity on the inbound channel. If the T_BS_Inactive timer expires the TS shall transition to the Hibernating 
state in accordance with in TS 102 361-2 [6], clause G.2.1. Here the TS shall cease transmitting, which deactivates the 
outbound channel. 

6.1 .2 Physical Channel Addressing 

The Tier III protocol supports a number of different physical channel strategies to accommodate operation in radio 
channels that may be dedicated, in blocks or allocated on an ad-hoc basis by an external agency. Physical radio channels 
may be specified by either: 

a) a logical channel plan whereby a transmitter and receiver frequency is mapped to a CHAN information 
elements. CHAN information elements permit up to 4 094 such logical / physical relationships; and/or 

b) a mechanism whereby the absolute transmitter and receiver frequencies are specified in the information 
elements of PDUs that are passed between DMR entities at the air interface. 

For b) there will be a degradation in performance over a) because the information that must be passed between entities 
is greater. However new physical/logical relationships that adds to or modifies the existing channel plan stored in MS 
may be broadcast on the TSCC. 

Annex C provides an illustration how the logical channels may be mapped to physical frequencies. 



6.1 .3 Sub-Division of the MS population 



Certain PDUs transmitted on the TSCC may be directed to and applicable only to a sub-set of the MS population. 
Examples are Aloha (C_ALOHA) PDUs and Broadcast (C_BCAST) PDUs. AppHcable PDUs contain a 24 bit address 
information elements and a 5 bit (Mask) number information element. The sub-set division is achieved by using the 
address qualifier (Mask) from the PDU. This parameter instructs a MS to compare the "Mask" least significant bits of 
its individual address with the "Mask" least significant bits of the address field from the PDU (containing the MASK) to 
determine if that PDU is applicable. 

A MS shall note the population subdivision contained in each applicable PDU that it receives. For Mask = to 24, the 
PDU is applicable to the unit if the "Mask" least significant bits of the Aloha address match the "Mask" least significant 
bits of its individual address. 

In this way, the MS population is effectively divided into 2^^^^subsets: 

• If Mask = then no address bits are compared, so there is no subdivision. 

• If Mask = 1 then only MS whose least significant individual address bit matches the least significant individual 
address bit from the PDU received shall consider the PDU to be applicable to that particular MS. 

This process continues up to Mask = 24. In this case the PDU is only applicable to one MS. 
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TSCC Outbound 
























Applicable Message 






Individual Address 
0000 0000 0010 1010 0001 IOOI2 




Address Mask 








1 24 bits 1 5 bits 










^^^ 


— ' — ' — — 




N\S 




^ ' 




|o|o|o|o|o|o|o|o|o|o|i|o|i|o|i|o|o|o|o|o|i|o|o|i| 
















. AAA 


o|o|o|o|o|o|o|i|o|i|o|i|o|o|o|o|i|i|o|o|i| 






|0|0|0 















Figure 6.1 : Example of PDU containing tlie "Mask" information element 

Figure 6.1 illustrates a MS personalized with the address 0000 0000 0010 1010 0001 IOOI2. 

A PDU is received that contains a Mask information element. The MS shall therefore determine if that PDU is 
applicable or the PDU shall be discarded. 

EXAMPLE 1 : The Mask information element contains the value OIOO2. 

The value of the Mask is 4 therefore the MS compares the 4 least significant bits of the address information 
element in the PDU received with the 4 least significant bits of the MS individual address. 



MS Indiv' Address 



000000000010101000001001 



Message Received 



00000000001010100001 1001 



Figure 6.2: Applicable PDU defined by Address and Mask 

The least significant 4 bits are compared as illustrated in figure 6.2. In this case the bits match so this IS an 
applicable PDU for this particular MS. (If Mask were any value from to 4 the PDU would still be 
applicable.) 



EXAMPLE 2: 



The Mask information element contains the value OIOI2. 



The value of the Mask is 5 therefore the MS compares the 5 least significant bits of the address information 
element in the PDU received with the 5 least significant bits of the MS individual address. 

The least significant 5 bits are compared as illustrated in figure 6.3. In this case the bits do NOT match so this 
PDU shall be discarded by this particular MS. (If Mask were any value from 5 to 24 the PDU would still be 
discarded.): 



MS Indiv' Address 
Message Received 



^0000000001010100000100^ 




[0^00000000010101000 11001 



Figure 6.3: Non-Applicable PDU defined by Address and Mask 
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6.2 



Random Access Procedures 



These clauses define the random access protocol, which is based on slotted Aloha that is used to: 

• control the collision of simultaneous random access attempts from different MSs; 

• manage the TSCC to minimize access delays; 

• ensure system stability; and 

• maintain optimum throughput under heavy traffic loads. 

Random access is the only access method permitted for MS on a fully regulated TSCC. For a Tier III system employing 
asynchronous access, and when the TSCC is de-keyed, the first random access attempt shall activate the physical TSCC 
channel whereupon the outbound burst shall regulate further signalling. 

6.2.1 The Random Access Principle 

The figures in the random access procedure clauses adopt the conventions illustrated in figure 6.4. 



' ' S I ot avai I ab I e f or random access 

^^^^^^^ Slot withdraw/n, random access not permitted 



I I 



PDU transmitted by a MS on the inbound 
channel 



PDU containing the back-off parameter 'N' 
on the outbound channel 

PDU that requires a response, i.e withdraw 
next TDMS frame (next but one slot) 



Figure 6.4: Conventions used in the figures 

In addition, the TDMA-slot and TDMA-Frame is illustrated in figure 5.1. 

PDUs transmitted on the TSCC on the outbound channel are divided between those that invite random access (such as 
Alohas) and those that withdraw one or more slots for the purpose of soliciting responses from MSs on the inbound 
channel (see clause 6.2.1.1.3). 



6.2.1.1 



Random Access Control 



The TSCC outbound channel creates an environment where TSCC access may be managed and controlled. This 
protocol specifies a specific C_ALOHA PDU that contains the information elements Random-Backoff, Mask, and 
Service Function, to manage and control random access. Other PDUs transmitted on the TSCC also contain the random 
backoff information element. 

All MS initiated services are by random access. If an MS wishes to make a random access attempt, the MS may send 
the random access service request PDU so long as: 

a) access is not inhibited by Mask (see clause 6. 2. 1.1.1); or 

b) access is not inhibited by the Service Function (see clause 6.2.1.1.2); or 

c) the slot chosen is not withdrawn (see clause 6.2.1.1.3). 



6.2.1.1.1 



Sub dividing the IVIS population 



C_ALOHA PDUs contain an address information element and a Mask information element. The procedure described in 
clause 6.1.3 is therefore applied. 

A MS shall note the population subdivision contained in each Aloha PDU that it receives. When attempting random 
access, the MS shall check if the population subdivision is applicable to it using the qualifier (Mask) and the address 
field from the Aloha PDU. For Mask = to 24, the PDU is appHcable to the MS if the "Mask" least significant bits of 
the Aloha address match the "Mask" least significant bits of its individual address. 

The subdivision is applied to subsequent TDMA frames marked PDUs that do not contain the Mask information 
element, until updated or changed by the next Aloha PDU. 
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In this way, the MS population is effectively divided into 2^^^^ subsets: 

• If Mask = then no address bits are compared, so there is no subdivision (under normal traffic loading, this 
will usually be the case). 

• If Mask = 1 then only units whose least significant individual address bit matches the Aloha address may send 
non-emergency random access PDUs. Thus the MS population has been divided into two subsets. 

• This process continues up to Mask = 24. In this case only one MS shall be permitted to make a random access 
attempt, (unless the MS requested an emergency service whereupon the MS may make a random access 
attempt for all values of Mask except Mask = 24). 

When a MS becomes active on a TSCC, including when returning from a payload channel, it shall either assume that 
the population is not subdivided (i.e. that the last C_ALOHA PDU was applicable to all MSs) or wait for a C_ALOHA 
PDU before attempting random access. 

6.2.1 .1 .2 Checking the Service-Function 

For service requests except emergency: 

• A MS shall use the Service Function from the C_ALOHA PDU. A MS shall not choose a slot for random 
access unless the random access attempt is for a service type invited by the Service Function information 
element. 

Table 6.1 : Service-Function 



Value 


Remark 


OO2 


Random Access invited for all Services 


OI2 


Random Access Invited for Services that require a 

physical payload channel 

Random Access Invited for registration requests 


IO2 


Random Access Invited for Services that do not 

require a physical payload channel 

Random Access Invited for registration requests 


II2 


Random Access invited for random access 
registration requests only 



• The Service function shall apply until the Service-Function is updated by a subsequent C_ALOHA PDU. 
For emergency service requests the MS is not required to check the Service-Function. 



6.2.1.1.3 



Withdrawing slots from Random-Access 



The TSCC may transmit a PDU (consisting of single block CSBK, multi block MBCs or multi-block UDTs) on the 
outbound channel that solicits a response from a specified MS. The MS response shall be sent in the next TDM A-frame 
following the last block of the TSCC PDU. In order to prevent a collision occurring between this solicited response and 
a random access transmission, the TSCC withdraws this timeslot, thereby prohibiting any random access transmissions 
in the given timeslot. The protocol makes use of the AT bit transmitted in the CACH to indicate to all MS that the 
following slot is withdrawn (see TS 102 361-1 [5], clause 4.5). (This, therefore implies that an MS intending to transmit 
a PDU by random access in a given timeslot shall successfully decode the appropriate CACH and note the value of the 
AT bit to ensure that the chosen timeslot has not been withdrawn from random access.) 
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In the following example in figure 6.5, when the TSCC transmits a PDU that requires a response, that PDU withdraws 
the following TDM A frame (slot but one). 



TSCC 
Outbound 



nzniniozoz 



CACH AT bit=busy 



EJZoznzniozEiJ 



MS 
Inbound 



fM^MJ 1 

C 



PDU inviting random access 



H 



Message requires a 
response from MSCB) 



Message that requires a response 
from an individually addressed MS 



-Response from MS(B) to the BS 



Slot available for random access 

W>Xfi Slot withdrawn, random access not 



Figure 6.5: Withdrawn Slots Example 

The TSCC transmits PDUs inviting random access: 

a) Aloha PDUs (see NOTE) invite random access. Therefore an MS is permitted to transmit a random access 
PDU. The CACH following each of the Aloha PDUs sets the AT bit to O2. Aloha PDUs never withdraw slots 
but an Aloha PDU with Mask=24, MS address=NULL, shall specifically prohibit random access even though 
the slot is not withdrawn; 

b) TSCC transmits a PDU that demands a response followed by the CACH with the AT bit set. The result is that 
the following slot but one at "C" is withdrawn - i.e. not available for random access. The TSCC withdraws that 
slot because the PDU "B" requires response from a specific MS(B); 

c) MS(B) transmits its acknowledgment PDU; 

d) if the slot chosen for the random access attempt is not available because the slot is withdrawn, the MS shall 
choose another slot for a subsequent random access attempt using the random backoff procedures specified in 
clause 6.2.1.1.6. 

NOTE: Other PDUs also invite random access. 



6.2.1.1.4 



TSCC responses to Random Access attempts 



After receiving a random access PDU, the TSCC shall send a response. Valid responses are specified in the clauses 
detailing the registration and call procedures. The response may be sent in the TDM A- frame following the random 
access PDU or it may be delayed. The TSCC shall use a NRand_Wait information element in the most recent 
C_ALOHA PDU to specify the delay (in TDMA-frames) a MS shall wait before choosing another slot using a random 
backoff timer for a repeat random access attempt. 



6.2.1.1.5 



Noting the response delay 



An MS shall note the delay parameter NRand_Wait from each C_ALOHA PDU it receives and shall use table 6.2 
below to derive from it the number of TDMA-frames, NWait, by which the TSCCs response to a random access PDU 
may be delayed. (NWait = means that the response is expected by the MS in the TDMA-frame following the random 
access PDU.) At the start of a session, until it receives an Aloha PDU, the unit shall assume a default value of 
NWait = NDefault_NW. 



Table 6.2: System Response delays indicated by the delay parameter NRand_Wait 



NRand Wait 


Nwait(TDMA-frames) 








1 


1 


2 


2 


3 


3 


4 


4 


5 


5 


6 


6 


7 


7 



NRand Wait 


Nwait(TDMA-frames) 


8 


8 


9 


9 


10 


10 


11 


11 


12 


12 


13 


13 


14 


15 


15 


24 
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6.2.1.1.6 



Random Backoff 



This clause specifies the method to manage the TSCCs receipt of random access PDUs. A system periodically 
broadcasts a random back-off timer (specified in TDM A frames). 

When a MS initiates a call, the MS may send its first random access PDU in the next slot (subject to Mask, Service 
Function and withdrawn slot specified in clauses 6.2.1.1 a), b) and c)). 

The MS shall invoke the random backoff procedures specified in this clause if: 

a) the MS could not make its random access attempt because access was inhibited by Mask; 

b) the MS could not make its random access attempt because access was inhibited by the Service Function; 

c) the MS could not make its random access attempt because the slot was withdrawn; 

d) the MS did make a random access attempt but that attempt was unsuccessful (the TSCC did not respond before 
the expiry of Nrand_Wait). 

If the MS makes a random access attempt and is unsuccessful, the MS shall choose a slot for its next random access 
attempt by choosing a random number between the limits of one and the backoff parameter using a statistically uniform 
distribution. 

Figure 6.6 shows a TSCC using parameters NRand_Wait=0. The most recent value of back-off received=4. 

Expected TSCC response window for Nrand_Wait=0 



TSCC ; 
Outbound i 


1 1 




1 


1 


1 


1 


1 


1 


1 


1 


1 


1 


1 


1 


1 


1 




1 


t 


] 




B 


3 


L 




2 




3 




4 








MS 
Inbound 





Figure 6.6: Random Backoff Example #1 

a) at [A] the MS makes a random access attempt. NRand_Wait=0 indicates that the TSCC will respond in the 
next TDMA frame at [B]; 

b) after TDMA frame [B] a response has not been received, therefore the MS chooses one of the slots 1, 2, 3, 4 
randomly for its next access attempt. 

Figure 6.7 shows a TSCC using parameters NRand_Wait=l. The most recent value of back-off received=4. 

Expected TSCC response window for Nrand_Wait=l 



TSCC 




1 1 


i 


L 
































t 


B 


! 1 2 3 4 


MS 
Inbound 





















Figure 6.7: Random backoff Example #2 

a) the MS makes a random access attempt. NRand_Wait=l indicates that the TSCC will respond in one of the 
next two TDMA frames at [B]; 

b) after TDMA frame [B] a response has not been received, therefore the MS chooses one of the slots 1, 2, 3, 4 
randomly for its next access attempt. 

A number of outbound channel PDUs including an Aloha PDU contain the backoff information element. 

NOTE: Future releases of the standard may define CACH messages that contain this information element. 
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The backoff may be altered by the TSCC and broadcast to MS to respond to varying load conditions presented to the 
system throughout the course of operation. If the system has a light traffic load, the backoff may be small, so decreasing 
random access latency. If the traffic load increases a longer backoff may be warranted to spread competing of random 
access attempts from different MSs by the TSCC transmitting a larger backoff number. This traffic load may be 
estimated from historical usage or may be calculated from the burst traffic being received at that time. 

The backoff parameter may change while the MS is already making random access attempts. When the MS has chosen 
a random slot, that slot shall be preserved for the duration of the current random access attempt. Any new value of 
backoff parameter from the TSCC shall be noted by the MS and shall be employed if the MS needs to choose a new 
random slot for its next random access attempt. 

For PDUs that contain the backoff information element, the number of backoff TDMA-frames is coded, so that more 
backoff TDMA-frames can be realized than a pure binary representation would permit. The explicit numbers of 
TDMA-frames resulting from the back-off number is indicated by table 6.3. 

Table 6.3: Number of backoff TDMA frames indicated by the Backoff Number 



Backoff Number 


Back-off TDIVIA Frames 





Reserved 


1 


1 


2 


2 


3 


3 


4 


4 


5 


5 


6 


8 


7 


11 



Backoff Number 


Back-off TDIVIA Frames 


8 


15 


9 


20 


10 


26 


11 


33 


12 


41 


13 


50 


14 


70 


15 


100 



Note that: 

a) a C_ALOHA PDU with M=24 invites access only for one specific individual MS; 

b) in the example in figure 6.5, if an MS had chosen the slot "C" for a random access attempt, that MS would be 
able to determine that the slot was not available for random access because the slot was withdrawn by 
decoding the AT bit from the CACH and noting that the slot the MS had chosen was withdrawn. The MS 
would abandon that random access attempt, and choose another candidate slot using the random backoff 
parameter; 

c) the MS shall rely on the AT bit to determine if the following random-access slot is withdrawn. If the MS does 
not successfully receive the preceding AT bit, the MS shall assume the slot is withdrawn. 



6.2.1.1.7 



Retry decision and time-outs 



After sending a random access PDU, a MS shall wait to receive a response from the TSCC. Various PDUs shall be 
accepted as a valid response (as specified in the clauses detailing the registration and call procedures). 

The MS shall abandon its access attempt if it has sent the maximum permitted number of random access for the 
particular service requested and received no valid response. This number depends on the service and priority of service 
being requested: 

• For non-emergency random access requests, it is NRand_NR. 

• For emergency random access requests, it is NRand_NE. 

The MS shall also operate a time-out TRand_TC that defines the maximum time it waits trying to achieve random 
access, and abandon the attempt if this time-out expires. 

If the unit's access attempt fails as a result of TRand_TC timeout then: 

a) if the MS has not transmitted a PDU, it shall return to the idle state (and may indicate the failure to the user); 

b) otherwise, (the MS has made at least one random access attempt) if the TRand_TC timer expires while the MS 
is waiting Nwait+1 for the last random access attempt, the MS will complete the Nwait+1 TDMA-frames 
before abandoning its random access. 
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6.2.1 .1 .8 Random Access (non-emergency) SDL for a MS as defined in clause 6.2 

Figures 6.8 to 6.10 illustrate the non-emergency random access procedures SDL. 



process RandomAccess 




Random Backoff 



1(3) 



r MS Random Access procedure fori 
n on -emergency call initiation. */ 



Idle 



MS has received matching 
n C_ALOHA PDU with random backoff, 
mask, service function, NRand_Wait 



PTT_REQ< 



set 
(TRand_TC) 



NRetry:= 




Inflate random access 
^servbe request 




'yes' 




yes 



'Select Random 
Access Slot 



(RandomBackOff, 
WaitSbt)' 



set 

(WaitSlot, 

TSelectedSlot) 



WaitRaSlot 



Figure 6.8 (sheet 1 of 3): Random Access Procedure SDL 
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process RandomAccess 



yes 



RandomBapOff 



WaitRaSlot 



TSelected^ot 








^-^SIo^\ 


Either by AT bit in CACH or 


^AAthdray\m'^ 


Mask=24 and MS Addr=NULL 




'no' 




C_RAND y 








N Retry := 
N Retry + 1 








set 
(TNWait) 


r 
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Figure 6.9 (sheet 2 of 3): Random Access Procedure SDL 
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Figure 6.10 (sheet 3 of 3): Random Access Procedure SDL 
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6.2.1 .1 .9 Random Access (emergency) SDL for a MS as defined in clause 6.2 

Figures 6.11 to 6.13 illustrate the emergency random access procedures SDL. 
process EmergencyRandomAccess 



/* MS Random Access procedure for 
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Figure 6.11 (sheet 1 of 3): Emergency Random Access Procedure SDL 
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Figure 6.12 (sheet 2 of 3): Emergency Random Access Procedure SDL 
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6.2.1.2 



Figure 6.13 (sheet 3 of 3): Emergency Random Access Procedure SDL 



Action after receiving an acknowledgement 



The MS shall not re-transmit any further random access PDU when an appropriate acknowledgement has been received 
from the TSCC. Various PDUs that are acceptable in addition to specific acknowledgement PDUs are indicated in the 
procedures specified in the present document. An applicable TSCC response to a random access request shall start an 
MS timer. This timer may be restarted by the reception of a further applicable acknowledgement PDU from the TSCC. 
Two values are specified for this timer. One value TP_Timer shall be used if the random access service requires a 
payload channel (for example a speech or packet data service). The second value TNP_Timer shall be used for services 
that only use the TSCC (for example Registration, Short Data service). 



ETSI 



51 ETSI TS 1 02 361 -4 VI .3.1 (201 0-06) 

6.2.1 .3 MS Arriving on a Control Channel 

Channel access regulation for trunked systems is implemented by a TSCC transmitting signalling on the outbound 
channel with periodic PDUs that define regulated channel access. 

When an MS tunes to a new channel where the recent history of channel activity is unknown, the MS shall establish that 
the TSCC is identified as one that the MS is permitted to access. 

a) The MS shall first wait until it receives a colour code information element. If the colour code being transmitted 
by the TSCC is OOOO2 the MS shall skip the colour code check and check the C_SYScode as specified in 
clause 6.2.1.3 b). If the colour code being transmitted by the TSCC is a value other than OOOO2 the MS shall 
check that this particular channel is transmitting a colour code that is expected by the MS. The MS may 
maintain a list of logical channel numbers and their corresponding colour code assignments (see annex C). 

b) The MS shall wait until it explicitly receives the C_SYScode being transmitted on the TSCC. If the MS is 
authorized to access this TSCC, the MS shall wait for an applicable C_ALOHA PDU before it attempts access 
by random access procedures defined in these clauses. 

6.3 Control Channel Acquisition and Retention 

Unless assigned to a payload channel (including immediately after switch-on), the MS shall attempt to find a TSCC 
appropriate to the MSs selected network. The search for a TSCC may be performed by a general hunt through all likely 
channels or by reference to parameters stored within the MS. A framework for MS hunting is described in annex D. 

A MS shall not make any transmissions on a TSCC unless it is active on that channel. It shall not become active until it 
has received a C_SYScode that authorizes the MS to access that TSCC. 

If an MS is hunting over a number of candidate channels, it shall leave the selected channel as soon as it becomes 
evident that the MS shall not be permitted service. 

The discipline for MSs whilst active a TSCC and the circumstances which may result in a search for a new TSCC are 
the subjects of clause 6.3.2 Control Channel Acquisition Procedures. 

In particular: 

• the method by which the MS searches for an appropriate TSCC; 

• the criteria to which a TSCC must be considered appropriate by the MS - authorization; 

• procedures for returning to the TSCC acquisition procedures. 

The methods specified in this clause recognize that designers of networks may choose from a variety of control channel 
strategies, including both Dedicated Control Channels and Non-dedicated Control Channels. 

These methods may result in the MS encountering a variety of control channel situations, including: 

a) receiving a TSCC which suffers short-term interruptions (radio fading and multi-path reception); 

b) suffering long-term interruptions to TSCC reception during which no appropriate TSCC can be received by the 
MS (Non-dedicated Control Channels, or moving out of range of the network); 

c) being in a location where it is possible for more than one TSCC to be received from the selected network, 
involving the unit in a choice; 

d) being instructed to leave a TSCC; 
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e) being instructed to leave or being barred from access to, a TSCC as a result of a network load sharing 
arrangement; 

f) being instructed to sample an alternative TSCC on an adjacent radio site (Vote Now). 

NOTE: It should be noted that a Non-dedicated Control Channel strategy may only be suitable for small single 

site trunked networks using only a few physical channels. If a multi-site trunked network employed a site 
with a non-dedicated TSCC, the network may find it impossible to connect a wide area call or transport 
services that only used the TSCC for delivery. 

Procedures have been specified in the present document to indicate to MS when they may sample an adjacent site for a 
TSCC that may provide an improved grade of service for the MS user. This is achieved on the TSCC transmitting a 
PDU that invites all MS to leave the TSCC momentarily. During this sample time the TSCC can discontinue call 
transactions. Notwithstanding this, manufacturers may devise their own procedures that will allow a MS to leave the 
current TSCC to sample for an alternative TSCC. However it must be noted that if the MS leaves the TSCC on its own 
volition the MS may miss a TSCC transaction. 

6.3.1 MS Parameter Volatility 

In order to satisfy the procedures specified in this clause, the MS shall retain certain parameters for each selected 
network when the MS is switched off. Other parameters shall be discarded when the MS is switched off. Table 6.4 lists 
the behaviour of each applicable parameter. MS parameters that are not listed in table 6.4 shall assume that it must be 
discarded when the MS is switched off. 

Table 6.4: MS Parameter Volatility for Control Channel Acquisition and Retention 



Parameter 


Clause 


Fixed during MS 

Personalization. 

Retained when MS is 

switched off 


Changes during 
operation and 

retained when MS 
is switched off 


Changes during 

operation and 

discarded when MS 

is switched off 


MODEL 


6.3.2.2.1.1 


X 






NET 


6.3.2.2.1.1 


X 






DMRLA 


6.3.2.2.1.1 


X 






MS Category 


6.3.2.2.1.3 


X 






Acquisition Authorization 
Data 


6.3.2.2.2 


X 

See note 






Logical Channel Hunt List 


Also see annex C 


X 






Additions to the hunt list 
from Announcements 
received 


7.2.19.1 




X 




Any parameter not listed 








X 


NOTE: Length of authorization data is dependent on MODEL. Huge - 10 bits, Large - 8 bits, Small - 5 bits. 
Tiny - 3 bits. 



6.3.2 Control Channel Acquisition Procedures 

Control Channel (TSCC) acquisition consists of the steps of checking the C_S YScode (verification) and, if successful 
measuring the signal quality (confirmation) as illustrated in figure 6.14. 
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VERIFICATION 

(Clause 6.3.2.2.2) <& 

(Clause 6.3.2.2.3) 



CONFIRMATION 
(Clause 6.2.2.3) 



I CONTROL CHANNEl\ 

VERIFICATION and 

I CONFIRMATION j 

\ ^ (Clause 6.3.2) ^ 




VERIFICATION 

and 
CONFIRMATION 



VERIFICATION 

or 
CONFIRMATION 



Figure 6.14: Verification and Confirmation Steps 



6.3.2.1 



Entry into TSCC Acquisition Procedures 



The TSCC acquisition procedures enable a MS that is not assigned to a payload physical channel to attempt to select a 
TSCC. TSCC acquisition is a procedure that consists of hunting for candidate TSCCs and attempting to verify that the 
MS is authorized to become active on that selected TSCC. 

The MS shall enter into the TSCC acquisition procedures under the following circumstances: 

a) immediately after switch-on; 

a user-initiated change of selected network; 

when it has relinquished the current TSCC under the procedures specified in clause 6.3.3; 

when it has received an applicable P_CLEAR PDU on a payload channel; 



b) 
c) 
d) 
e) 



when it has sent disconnect PDUs P_MAINT(Maint_Kind=DISCON) or timed-out on a payload physical 
channel; 

f) when it has received a call P_AHOY(Service_Kind=l 1 1 12 Cancel Call Service) PDU on a payload physical 
channel which requires it to vacate that physical channel. 

At all times during the TSCC acquisition procedures the MS shall mute its received audio and transmission shall be 
inhibited. 

A framework for TSCC control channel hunting is provided in annex D. 



6.3.2.2 



Identifying a Candidate Control Channel 



When an MS is searching for a suitable control channel, the MS shall examine any signal detected for conformity with 
TSCC structure. The MS shall accept as a candidate TSCC any channel on which a TSCC synchronization sequence is 
detected. 

The method by which the MS identifies candidate TSCCs during hunting is not detailed in the present document. In 
particular no maximum time allowance for this procedure is specified, although attention is drawn to the necessity of 
completing tests as quickly as possible, notably on channels which can be easily rejected as TSCC candidates 
(e.g. invalid parameters from the C_SYScode), since the overall speed of the hunt (and thus efficiency of service to the 
user) depends on the rapidity with which these tests can be carried out. 
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6.3.2.2.1 



Checking the System Identity Code 



When the MS has identified a candidate TSCC, it shall examine the values of the C_S YScode fields from the TSCC 
PDUs that transmit the C_SYScode information element. 

The time which the MS may continue to search for a value of C_S YScode information element for verification is not 
specified since this depends on the regularity by which the TSCC transmits PDUs that contain the C_SYScode 
information element. However it should be noted that the essential C_SYScode parameters for TSCC searches are also 
transmitted in the CACH. 

When the MS has selected a C_S YScode information element for verification, it shall decide if it is authorized to 
acquire the TSCC (see clause 6.3.2.2.2). If acquisition is permitted then the MS shall become active on that TSCC and 
start the signal quality checking procedures specified in clause 6.3.2.3. 

Whilst active on a TSCC, after verification but prior to confirmation, the MS shall not transmit any random access 
PDUs, but it shall comply with any applicable PDUs received, as required, provided that to do so does not involve 
transmitting on the TSCC. 



6.3.2.2.1.1 



Structure of the System Identity Code (C_SYScode) 



DMR trunked networks may range from tiny systems consisting of a very small number of sites to very large systems 
covering a wide geographic area. To accommodate this wide range of networks, DMR specifies four network models, 
each with characteristics appropriate to each model. 

Table 6.5: Network Model 



Network 
Model 


Model 
Coding 


Number of 
Networks 


Number of Sites 
per Network 


DMRLA 


Tiny 


OO2 


512 


8 


0to3 


Small 


OI2 


128 


32 


0to5 


Large 


IO2 


16 


256 


0to8 


Huge 


II2 


4 


1 024 


OtolO 



In order to identify the network and site to MSs, a TSCC frequently transmits a C_SYScode. MSs shall examine the 
C_SYScode to determine if they are permitted to become or remain active on the TSCC. The C_SYScode information 
elements are structured as follows. 

Table 6.6: Network Model Description 



Parameter 


Descriptor and section 


Description 


MODEL 


Network Model 


Tiny, Small, Large, Huge 


NET 


Network Identity 


Identifies a particular DMR trunked network 


SITE 




The SITE parameter identifies a particular site within a network 


PAR 




for multiple TSCCs within one TS (site) 



A bit specific representation of the Syscode information element is illustrated in figure 6.15. The MODEL defines the 
length of the NET and SITE information elements. Table 6.5 shows the effect of this partition. It is likely that in a 
particular geographical area a large number of small networks may be employed but only a small number of large 
networks. The MODEL parameter enables a number of differing archetypal networks to be defined. 

NOTE: The DMRLA parameter illustrated in figure 6.15 is used for registration. The registration protocol is 
specified in clause 6.4.4). 
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6.3.2.2.1.2 



DMRLA(n) n=0 to 10 

Figure 6.15: Allocation of NET and SITE information elements in C_SYScode 

Multiple Control Channels 



DMR trunked networks may operate with one or two TSCCs at a single site. The site may sub-divide the MS population 
to allow load sharing between TSCCs. This facility is provided by the PAR sub-field in the C_SYScode and by control 
categorization of MSs. 



6.3.2.2.1.3 



Control Categorization of Radio Units 



At the time of MS network personalization, the MS shall be allocated a control category (ContCAT) stored in the MSs 
fixed non- volatile storage. Two control categories are available, which are designated A and B. 

The control category governs acquisition and retention of a TSCC, since the PAR sub-field in the C_S YScode indicates 
which MS control categories are allowed to become active. 



6.3.2.2.1.4 



The PAR Sub-field 



The PAR information element occupies two bits of the C_S YScode. The meanings assigned to the four possible values 
of PAR shall be: 

OO2 Reserved. 

OI2 Category A MSs only permitted. 

IO2 Category B MSs only permitted. 

1 12 Category A MSs and B MSs permitted. 
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ITraffic : 


1 


Traffic 1 


T5CC PAk=Olz 


TSCC PAR=102 



Site - 2 



Traffic 



Traffic 



TSCCPAR=ll2 




e 



d i i 



i 



Site - 3 



d i 



i 



Traffic 



Traffic 



TSCCPAR=ll2 



EXAMPLE: 



6.3.2.2.2 



Figure 6.16: Multiple Control Channels by PAR 

A wide area DMR trunked network has a number of radio sites that employ one TSCC and one site 
that is equipped with two TSCCs. Differing fleets of MS are personalized such that the total MS 
population is evenly distributed between Category A and Category B units. Referring to 
figure 6.16, Site T is configured with two TSCCs and radiates PAR=01 on the first TSCC and 
PAR=10 in the second TSCC. Any MS, whether Category A or B can become active on the TSCC 
from site 2 and site 3. When MS travel to site 1 however they will cluster on their appropriate 
TSCC. 

TSCC Authorization Procedure 



The MS shall read the C_SYScode being transmitted on the TSCC: 

a) Checking the MODEL: 

The MS shall compare the MODEL transmitted in the C_SYScode on the TSCC with the MODEL stored 
in MS fixed non-volatile storage. If there is no match then the MS unit shall assume that it is not 
authorized to acquire the TSCC under test. 

b) Checking the NET: 

If the MS has successfully verified a) above then: 

■ The MS shall compare the NET transmitted in the SYS code on the TSCC with the NET stored in 
MS fixed non- volatile storage. If there is no match then the MS unit shall assume that it is not 
authorized to acquire the TSCC under test. 
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c) Checking the SITE_Acquisition Authorization Data: 

If the MS has successfully verified a) and b) above then: 

■ The MS shall first check if it has stored any SITE acquisition authorization parameters. If no SITE 
acquisition authorization parameters are stored then no checking of SITE acquisition authorization 
shall be performed. However if the MS holds at least one parameter, each value stored shall be 
compared with the SITE parameter transmitted in the C_SYScode on the TSCC. If there are no 
matches then the MS unit shall assume that it is not authorized to acquire the TSCC under test. 

d) Checking the PAR sub-field: 

If the MS has successfully verified a), b) and c) above then it shall examine the PAR sub-field in the 
light of its control category held in fixed non- volatile storage. If the control category of the MS is not one 
of the categories permitted access by the PAR sub-field value, then the MS shall assume that it is not 
authorized to acquire the TSCC under test. 



MODEL 


NET 




Acquistion Auth' 


Data 


Acquistion Auth' 


Data 


Acquistion Auth' 


Data 


Acquistion Auth' 


Data 


Acquistion Auth' 


Data 


Acquistion Auth' 


Data 


Acquistion Auth' 


Data 


Acquistion Auth' 


Data 




CAT (A,B) 




Figure 6.17: Checking tlie C_SYScode 

Figure 6.17 illustrates the TSC Authorization procedure specified in clause 6.3.2.2.2 a), b), c) and d). 



6.3.2.2.3 



Checking the SYS_AREA information element 



If the MS has successfully verified the C_SYScode (according to clause 6.3.2.2.2), then it shall examine the 
SYS_AREA information element from the C_SYScode. The SYS_AREA is formed by applying a mask to the Site 
information element of width specified by DMRLA. 



ETSI 



58 



ETSI TS 102 361-4 V1.3.1 (2010-06) 



The S YS_AREA information element is then compared with a Hst in the Hght of denied registrations appHcable to the 
selected network held by the MS. (That list is discarded when the MS is switched off. see clauses 6.3.2.2.2 and 6.4.2). 

If the value of the S YS_AREA information element under examination matches with any of the records of denied 
registrations applicable to the selected network, then the MS unit shall not be authorized to acquire the TSCC under test. 
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t4\S is NOT Authorised to become 
active on TSCC under test 



Figure 6.18: SYS_AREA information element from tlie C_SYScode 

EXAMPLE: A large network has MS personalized with DMRLA=6. The MS retrieves the SYS_AREA 

information element from the C_S YScode and compares that result with each entry in the list of 
denied registrations. If there is a match in any one of the entries then the MS shall not be 
authorized to acquire the TSCC under test. 

6.3.2.2.3.1 Lifetime of SYS_AREA entries in the denied registration list 

The entire denied registration list is discarded when the MS is switched off (see clause 6.4.2). 

If the timer T_DENREG is non-zero, individual entries in the denied registration list shall have a limited lifetime. In 
this case the MS maintains a timer for each of the entries. If the timer for a particular SYS_AREA expires, that 
S YS_AREA shall be removed from the list. 

6.3.2.3 Confirmation - Monitoring the TSCC outbound channel signal quality 

While idle on a control channel the MS shall determine the outbound channel signal quality. This may be 
e.g. examination of the error rate, from measurement of the RE signal strength. 

The MS shall hold two thresholds of signal quality: 

a) One threshold shall be used while the MS is hunting for a TSCC prior to confirmation (see clause 6.3.2). 

b) The second threshold shall be used after verification and confirmation and the MS is idle on the TSCC. 
NOTE: When an MS enters a call set-up phase, it suspends signal quality measurement of the TSCC. 
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6.3.3 MS Leaving a Control Channel 

6.3.3.1 Reasons for Leaving a Control Channel when active but idle 

When active, the MS shall monitor the TSCC and return to hunting procedures if any of these conditions are met: 

a) After confirmation, the bit error rate exceeds the minimum prescribed in clause 6.3.2.3. 

b) The value of C_ S YScode received differs from the value verified during acquisition authorization for a 
NSYSerr consecutive occurrences. 

c) No decodable TSCC PDUs are received by the MS for T_Nosig seconds. 

d) The user initiates a change of selected network. 

e) A C_MOVE PDU applicable to the MS is received . In this case the MS shall note the value of the CONT 
information element from the C_MOVE PDU. 

f) The MS receives C_NACKD(Reason=Reg_Denied) as a result of sending a random access registration PDU. 
In the case of a random access registration request, the MS shall assume the hunt stage that it was last engaged 
in prior to the registration attempt. 

g) After C_S YScode confirmation, the MS receives C_NACKD(Reason=Reg_Refused) as a result of random 
access registration procedures. In this case the MS shall assume the hunt stage that it was last engaged in prior 
to the registration attempt. 

h) After confirmation, the MS has timed out after a random access registration procedure due to NRand_NR 
being reached or Trand_TC being exceeded. In this case the MS shall assume the hunt stage that it was last 
engaged in prior to the registration attempt. 

i) After confirmation, the MS has timed-out after a random access attempt for a service request, except 
registration, due to NRand_NR or Nrand_NE being reached or Nrand_TC being exceeded. 

6.3.3.2 Leaving a Control Channel Whilst Waiting for Signalling 

A MS waiting for signalling shall leave the TSCC on which it is currently active when any of the following events as 
listed in clause 6.3.3.1 occur - b), c), e). In such circumstances the MS shall retain its state of waiting for signalling 
during any hunting procedures and subsequent TSCC confirmation tests. Any timers relevant to the waiting state shall 
be maintained. 

6.4 Registration, Power Save, and Authentication Procedures 

The procedures defined in this clause support the generic and supplementary services. PDUs exchanged between the TS 
and MS contain device addresses that either identify a specific device (such as an MS), or a gateway (see clause A.4) 
that indicates the service being supported. For clarity the service, the PDUs and addresses are illustrated in table 6.7. 



ETSI 



60 



ETSI TS 102 361-4 V1.3.1 (2010-06) 



Table 6.7: Services - PDUs - addresses cross reference 



Service 


PDU 


Source 


Source 
Address 


Destination 
Address 
(Target) 


Notes 


Registration 


Random Access 
Request 


MS 


MS ID 


REG_ADDR 


0000 OOOO2 + C_SYScode 


Acknowledgment 


TS 


REGI 


MS ID 


To the Random Access 
Request or final 
acknowledgement if the 
registration was subject to 
authentication 


MS Authentication 
or part of registration 


C_AHOY 


TS 


Authentication 
Challenge 


MS ID 




Acknowledgment 


MS 


Authentication 
Result 


MS ID 


To the Authentication 
Challenge 


Stun/Revive 


C AHOY 


TS 


STUNI 


MS ID 




Acknowledgment 


MS 


MS ID 


STUNI 


To the C_AHOY or final 
acknowledgement if the 
stun/revive was subject to 
authentication 


Stun/Revive (IVIS 
authenticates TS) 


C AHOY 


TS 


STUNI 


MS ID 




C_ACVIT 


MS 


Authentication 
Challenge 


AUTHI 




Acknowledgment 


TS 


AUTHI 


Authentication 
Result 




Acknowledgment 


MS 


MS ID 


AUTHI 




MS Kill with 
authentication 


C AHOY 


TS 


KILLI 


MS ID 


Kill shall always be 
authenticated 


C_ACVIT 


MS 


Authentication 
Challenge 


KILLI 


Acknowledgment 


TS 


KILLI 


Authentication 
Result 


Acknowledgment 


MS 


MS ID 


KILLI 


Registration with IP 
connection Advice 


Random Access 
Request 


MS 


MS ID 


REG_ADDR 


0000 OOOO2 + C_SYScode 


Acknowledgment 


TS 


REGI 


MS ID 


C WACK or C NACK only 


C AHOY 


TS 


IPI 


MS ID 




C UDTHU+AD 


MS 


MS ID 


IPI 




Acknowledgment 


TS 


IPI 


MS ID 




MS Radio Check 


C AHOY 
P AHOY 


TS 


TSCI 


MS ID or 
Talkgroup 


IG indicates individual or 
talkgroup 


Acknowledgment 


MS 


MS ID 


TSCI 




Supplementary_user 

data Services 

supporting primary 

service 


C_AHOY 


TS 


SUPLI 


Calling Party 
MS ID 


Inbound phase 


C UDTHU+AD 


MS 


MS ID 


SUPLI 


C_UDTHD+AD 


TS 


SUPLI 


Called Party 
MSID 


Outbound Phase if applicable 


Acknowledgment 


MS 


MS ID 


SUPLI 



6.4.1 Registration 



6.4.1.1 



Introduction 



Registration is a method of recording the area or group of areas where a MS is likely to be located within a wide area 
network. This information avoids searching for MSs throughout the whole network, consequently reducing call set-up 
time and TSCC loading. 

A secondary feature is that it provides a means of restricting the service to individual MSs to specific TSs by allowing 
the network to deny other registration requests (see clause 6.4.4.1.4). 
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The registration strategy describes two types of registration. The first of these is expHcit registration, where registration 
is achieved by means of a MS random access procedure. The second is impHcit registration, where registration is 
achieved as the result of any PDUs exchanged between a TSCC and a MS. 

ExpHcit registration also enables MS to request power save. Power save is prescribed in clause 6.4.7. 

A simple MS radio check procedure enables the TSCC to simply poll an individual MS for its presence at any time. 
This procedure is described in clause 6.4.12. 



6.4.1.2 



The Principle 



The principle of registration requires that the MS shall only retain a valid registration record where it has received 
confirmation that it is the same record as that currently held within the network. If a MS fails to receive a response to a 
registration request, this could be due to: 

a) the registration request not being received by the network, in which case the network will regard the previous 
successful registration by the unit as the currently- valid registration record; 

b) the registration request being accepted by the network but the service answer response not being received by 
the MS, in which case the network will regard the unsuccessful registration by the unit as the currently- valid 
registration record. 

Accordingly, in such cases the MS is not able to confirm whether the network holds a valid record for the unit and if it 
does, whether it is the previous registration or the present registration. The MS shall therefore only replace its current 
registration record when a successful registration is confirmed by a suitable service answer response to the registration 
service random access request from the TSCC. 

The registration record shall be extracted from the C_SYScode using the following procedure: 

c) The MS extracts the SITE parameter from the C_SYScode. 

d) The MS then extracts the S YS_AREA information from the SITE parameter by masking the most significant 
bits (MSBs) with DMRLA. 

C_SyScode 



16 


15 


14 


13 


12 


11 


10 


9 


8 


7 


6 


5 


4 


3 


2 


1 


1 


































MODEL NET 

LARGE NETWORK 



_>^__ 



SITE 



DMRLA=6 



PAR 



AREA Sub Field 



Registration Record 



__y 



Figure 6.19: Extraction of the registration record from tlie C_SYScode 

EXAMPLE: Figure 6.19 shows a Large Network. The SITE parameter for a Large Network has a field length 
of 8 bits. DMRLA in this example=6, therefore the most significant 6 bits become the registration 
record. 
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6.4.2 MS Parameter Volatility 

In order to satisfy the procedures specified in this clause and annex D, the MS shall retain certain parameters for each 
selected network when the MS is switched off. Other parameter shall be discarded when the MS is switched off. 
Table 6.8 lists the behaviour of each applicable parameter. 

Table 6.8: MS Parameter Volatility for Registration 



Parameter 


Clause 


Fixed during MS 
Personalization. Retained 
when MS is switched off 


Changes during 

operation and retained 

when MS is switched off 


Changes during 
operation and discarded 
when MS is switched off 


The Current 
Registration Record 


6.4.4 




X 




List of Denied 
Registrations 


6.3.2.2.3 
(see note 1 ) 






X 


NOTE 1 : At least 8 different values of SYS_AREA information element from the received C_SYScode verified when 

acquiring the TSCC on which a registration attempt by the MS has been denied. These shall be managed as a 
FIFO list: when the MS has a full list of entries, any further addition to the list shall displace the earliest entry. 

NOTE 2: Individual entries in the Denied Registrations list may be deleted by expiry of the denied registrations timer 
T DENREG (see clauses 6.3.2.2.3.1 and 6.4.4.1.4). 



6.4.3 Action on confirmation of a TSCC 

A MS shall not make any attempt at random access until TSCC confirmation has been achieved. 
When a MS confirms a TSCC it shall either: 

a) if the Reg information element (carried in C_ALOHA PDUs and in the CACH) is zero, the MS shall not seek 
to register by random access nor shall it create or alter any registration record. The MS shall note that 
registration is not required and that it is free to initiate calls; or 

b) if the verified S YS_AREA information element from the C_S YScode matches any entry in the list of denied 
registrations then the MS shall not be authorized to acquire the TSCC under test. The MS shall resume 
hunting; or 

c) if the MS does not hold a successful registration record for the verified S YS_AREA, the MS shall attempt to 
register by random access. 

Once confirmed on a TSCC, the MS shall not transmit any PDU other than: 

a) registration service random access request PDU; or 

b) an acknowledgement to an authentication challenge as specified in clause 6.4.8.3; 

until it holds a successful registration record relating to the verified SYS_AREA unless Reg = 0. 

If the MS holds a successful registration record relating to the verified S YS_AREA code, it is free to transmit any PDU 
conforming to the requirements of the present document. 

6.4.4 Registration Procedures 

The procedures for explicit MS registration are prescribed in clauses 6.4.4.1 to 6.4.4.9. Figures 6.21 to 6.23 illustrate the 
registration process MSCs including the optional authentication step. 



6.4.4.1 



Registration by Random Access 



When a MS determines that it is required to register, it shall attempt to do so by random access using the procedures 
defined in clause 6.2. If the random access timeout C_RandTC expires and the MS has not sent a random access 
registration request, the MS shall enter the TSCC acquisition procedures. 

The information elements in the random access request are passed to the CC layer - set appropriately as prescribed in 
table 6.9. 
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Table 6.9: C_RAND information elements for the MS Registration Service 



Information Element 
(I.E), I.E 


Length 


length 


Alias 


Value 


Remark 


Service_Options 


7 


1 




O2 


Reserved 


1 




O2 


Privacy (see note 1 ) 


1 


IPJNFORM 


O2 


MS is not advising IP connection 


I2 


MS is advising IP connection 


3 


PS_RQ 


O2 


Power Save not requested 


OOI2 

tOl1l2 


Power Save requested 


1 


REG_DEREG 


O2 


If IP_lnform=02theMSis 

attempting to de-register. 

If IP_lnform=l2the MS is deleting 

an IP connection 


I2 


If IP_lnform=02theMSis 
attempting to register. 
If IP_lnform=l2the MS is 

attempting to register and/or adding 
an IP connection 


Proxy Flag 


1 




PROXY 


O2 




Appended 
Supplementary_Data 


2 




SUPED_VAL 


OO2 




Reserved 


2 






OO2 




Service_Kind 


4 




REG_SRV 


IIIO2 


Registration Service 


Target_address or 
Gateway 


24 




REG_ADDR 


Value 


Registration Address (see note 2) 


Source_address 


24 






Value 


Individual Address of the 
requesting MS 


NOTE 1 : Privacy is not defined in the present document. 

NOTE 2: REG_ADDR is an information element that is formed from 0000 OOOO2 + C_SYScode 



Immediately upon sending the registration request by random access, the MS shall delete its current SYS_AREA code 
retained from its previous registration. 

Valid TSCC responses to the random access request are C_WACKD(Reason=Wait) more signalling to follow, 
C_ACKD(Reason=Reg_ Accepted), C_NACKD(Reason=Reg_Refused), C_NACKD(Reason=Reg_Denied), or 
C_AHOY(Source Address=Authentication_Challenge) (see clause 6.4.8). ACK type PDUs shall set the target address 
to REGI and the Source Address to the MS individual address. 

The TSCC shall only send a response to the random access request if the C_S YScode in the REG_ADDR information 
element of the C_RAND matches the C_S YScode being transmitted by the TSCC. If the REG_ADDR information 
element in the C_RAND received by the TSCC does not match the C_SYScode being transmitted by the TSCC, the 
TSCC shall discard the C_RAND registration message. 

NOTE: REGI is the registration identifier (see clause A.4). 



6.4.4.1.1 



Intermediate Acknowledgement 



If the TSCC cannot respond immediately to the random access request, it can send a C_WACKD(Reason=Wait) to the 
MS. This acknowledgement shall start timer TNP_Timer in accordance with clause 6.2.1.2. If further signalling is not 
received after the expiry of the timer, the MS shall comply with the procedures in clause 6.4.4.1.6. 



6.4.4.1.2 



Registration accepted 



The registration attempt shall be considered successful on receipt of ACK(Reason=Reg_Accepted). The MS shall 
record the SYS_AREA information from the TSCC C_SYScode. The MS shall replace any old registration record with 
the new record extracted from the C SYScode. 
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6.4.4.1.3 



Registration Refused 



The registration attempt shall be considered to have been unsuccessful if the MS receives 
C_NACKD(Reason=Reg_Refused). 

The MS shall resume hunting, and after confirming a TSCC and receiving a suitable C_ALOHA PDU, shall 
re-commence a random access registration attempt. 

Until a successful registration is achieved, the MS shall not attempt to transmit other than random access registration 
service requests. 



6.4.4.1.4 



Registration Denied 



The registration attempt shall be considered denied if the MS receives C_NACKD(Reason=Reg_Denied). The MS shall 
add the SYS_AREA code to the list of denied registration records and enter the TSCC acquisition procedures. 

If T_DENREG is non-zero the MS shall start a timer equal to the value of T_DENREG for that entry in the denied 
registration list. 

6.4.4.1 .5 Challenge and Response Authentication 

The TSCC may apply an intermediate step of authenticating the MS during the registration procedure. 

- D 



TSCC 
Outbound 



W T^ [^ " F<1 K 



MS(A) 
Inbound 



AK 



^Challenge I I Response 1 1 

Figure 6.20: Registration with authentication check 

Figure 6.20 shows a MS registration procedure with the optional steps "B" and "C": 

a) At "A" the MS makes a random access registration attempt. 

b) The AHOY PDU at "B" is the acknowledgement to the random access and challenges the MS to respond with 
its authentication response. The timer TNP_Timer timer is started. 

c) "C" is the MS response to the TSCC containing the authentication response. 

d) The final C_ACKD or C_NACKD is sent by the TSCC to the MS. 
The specific authentication procedures are prescribed in clause 6.4.8. 



6.4.4.1.6 



Registration Attempt Times Out 



If the MS times out from waiting for further signalling for the registration (expiry of timer TNP_Timer), it shall enter 
the TSCC acquisition procedures. 



6.4.4.1.7 



Registration Demand Received During Random Access Registration 



The TS shall avoid conflict in the protocol. If, while waiting for a response to a random access registration request 
PDU, the MS receives a C_BCAST(Announcement_type=MassReg) PDU applicable to the MS, the MS shall note the 
information elements from the C_BCAST and initiate the procedure specified in clause 6.4.5.1 then continue with its 
registration request in accordance with the random access procedures. 
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6.4.4.1 .8 No answer response Received after the maximum number of random access 

attempts 

If no response is received within WAIT+1 slots after the MS has transmitted NRand_NR random access attempts, the 
MS shall make no consequential changes to its registration record. 



6.4.4.1.9 



Registration Action on Switch-on or equivalent 



If an MS determines that the TSCC requires MS to register, the MS shall register by random access on switch on or 
change of selected network. 

6.4.4.1 .10 Registration scenario IVISC 

Illustration of the explicit registration procedure as defined in clauses 6.4.4.1 to 6.4.4.9. 



MSC MS_Registration 



Successful 
registration 



Failed 
registration 



Denied 
registration 



Failed 
registration 



CCL MS 



DLL 



Tx C RAND 



(Registration) 
NWait 



Tx_CSBK 



(C_RAND) 



alt I 



Rx C ACKD 



( Reg_Accepted) 
Rx CNACKD . 



(Reg_Failed) 



Rx_CNACKD 



(Reg_Denied) 



TNP_Timer 



PL 



optj 


Rx_C_WACKD 


Rx CSBK 


1 
1 




(C_WACKD) 


NWait 


(Wait) 


TNP Timer 

X7 





optj 


Rx_C_AHOY 


Rx_CSBK 


1 
1 


Tx_CSBK 


(C_AHOY) 


(Authentication challenge) 
NWait 


TNP_Timer 


Tx_C_ACKU 


(Authentication response) 


(C_ACKU) 





Rx_CSBK 



(C_ACKD) 
Rx_CSBK 



(C_NACKD) 



Rx CSBK 



(C_NACKD) 



Figure 6.21 : MS Registration MSC 
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6.4.4.1.11 



Registration with IVIS authentication 



process RegistrationWithAuthentication 



/* Example of MS performing successful registration 
with authentication procedure. V 



WaitRaSlot n 



Registration required has 
^ been identified and the random 
access slot selected. 



TSelectedSlot n 



Assumed to occur before 
TRand_TC timeout 



'MaskCheck' 



C_RAND 
(registration 



N Retry := 
N Retry + 1 



J Assumed to result in 
selected slot available 



set 
(TNWait) 



WaitTsRsp 



J Set a timer/counter for the NWait 
time 



1(2) 



Figure 6.22 (sheet 1 of 2): Registration with Authentication SDL 
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process RegistrationWithAuthentication 



2(2) 




Assumed to occur before 
timeout of TNWait and TC_RAND 



(challenge, key, authresp) 



C_ACKU 
(authresp) 



WaitRegAck 



WaitRegAck 



C_ACKD / _ J Assumed to occur before 
(Reg_Acce|3ted) timeout of TNP_Timer 



reset 
(TNP_Timer) 



Active 



6.4.4.1.12 



Figure 6.23 (sheet 2 of 2): Registration with Authentication SDL 



Acceptance of user initiated service requests 



For voice and data services, users request a particular service by transmitting a random access service request. The 
TSCC may require MS to be registered with that TSCC before accepting such a service request. If the TSCC is 
configured such that service requests are only accepted to registered MS and a MS that is not registered makes a service 
request then the TSCC shall respond with a C_NACKD(Reason= MS_Not_Registered). 

6.4.5 Mass re-registration 

A wide area network relies on the integrity of the registration records for MS location management. It is possible that 
the records may be suspect for many reasons including loss of connections between the various TS. This clause 
describes a mechanism whereby a TSCC may re-establish those registration records from the MS that are currently 
confirmed on that TSCC. A broadcast PDU is transmitted on the TSCC that causes all applicable MS that are confirmed 
to re-register by random access. If this re-registration procedure is activated it is essential to avoid congestion from the 
increased random access activity that would result. To manage this process therefore, a Reg_Window information 
element is transmitted in the broadcast PDU that permits MS to make their random access registration attempt over an 
extended period of time. 
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An MS shall note the delay parameter Reg_Window from the C_BCAST(Announcement_type=MassReg) PDU it 
receives and shall use table 6.10 to derive from it a time window to make a random access registration attempt. 

The Mass registration may be used to demand a registration from a specific MS by setting the MS address in the Mass 
Registration Broadcast PDU to the individual address of a MS and setting the Mask = 24. 

6.4.5.1 Procedure for MS on receipt of Mass Re-registration Broadcast 

When confirmed on a TSCC a MS shall make use of information C_BCAST(Announcement_type=MassReg). This 
PDU may be transmitted on the TSCC to cause all MS or a subset of the MS population to re-register by random access. 

A MS shall note the population subdivision contained in each C_BCAST(Announcement_type=MassReg) PDU that it 
receives (as prescribed in clause 6.1.3) using the qualifier (Mask) and the address field from the C_BCAST PDU. For 
Mask = to 24, the PDU is appHcable to the MS if the "Mask" least significant bits of the C_BCAST address 
information element match the "Mask" least significant bits of its individual address. 

Table 6.10: Reg_Window lookup for Mass-Registration 



Reg Window 


Treg Window 





Cancel Mass Reg 


1 


0,5 


2 


1 


3 


2 


4 


5 


5 


10 


6 


20 


7 


30 



Reg Window 


Treg Window 


8 


100 


9 


300 


10 


1 000 


11 


3 000 


12 


10 000 


13 


30 000 


14 


100 000 


15 


200 000 



If the MS determines that the C_BCAST(Announcement_type=MassReg) PDU is appHcable, the MS shall: 

a) examine the Reg_Window information element from the C_BCAST(Announcement_type=MassReg). If the 
Reg_Window information element is non-zero, the MS shall derive the window size TReg_Window (in 
seconds) for a Random Access Registration attempt using table 6.10; 

b) choose a random number (using a statistically uniform distribution) from zero to TReg_Window; 

c) count real time seconds until the random value is reached; 

d) make a random access registration attempt using the procedures prescribed in clause 6.4. If the MS is in power 
save mode, the PowerSave_RQ information element in the Service_Options of the registration service request 
shall be set to maintain the power save mode currently in operation; 

e) also count real time seconds until the TReg_Window slot is reached. If the MS receives other applicable 
C_BCAST(Announcement_type=MassReg) containing a non zero Reg_Window information element before 
Reg_Window is reached the MS shall ignore that C_BCAST PDU; 

f) if Power Save is in operation, the TSCC shall ensure that the Mass-Registration is transmitted in the wake 
period. 

If the MS is confirmed on a TSCC and the MS receives other applicable C_BCAST(Announcement_type=MassReg) 
containing a zero Reg_Window information element the mass re-registration procedure and any pending random access 
attempt shall be cancelled. If such a broadcast is received when the random access procedure is in progress that random 
access procedure shall be completed before the mass re-registration procedure is cancelled. 

If the MS leaves the currently confirmed TSCC, and successfully confirms a different TSCC, any Mass -registration 
procedure shall be cancelled. 

6.4.6 De-registration 

When an MS is switched off, or a user initiated change of system is invoked, the MS may first attempt to de-register 
from the current system. It shall attempt to do so by random access using the procedures defined in clause 6.2. In the 
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Service_Options of the registration service request the information elements shall be set to IP_Inform=02, 
Reg_Dereg=02 and PowerSave_RQ=0002. 

When an MS switch-off or change of network is performed, the MS shall start a timer T_Dereg. 

Immediately upon sending the de-registration request by random access, the MS shall discard its current SYS_AREA 
code retained from its previous registration. 

The only valid TSCC response to the de-register random access request shall be C_ACKD(Reason=Reg_Accepted). If 
the acknowledgement is received, the MS shall complete the switch off or change of network. 

If timer T_Dereg expires, the MS shall abandon the de-registration procedure and complete the action of switch-off or 
change of network. 

6.4.7 Power Save 
6.4.7.1 Overview 

Tier III systems may support a synchronized power saving feature. 

An MS can synchronize to the timing parameters that have been exchanged with the TSCC and adopt a periodic sleep 
cycle. Calls to that MS shall be synchronized to the wake-up periods (power save frames) that are agreed between MS 
and the TSCC. 

I POWER SAVE FRAME = 480mS for TDMA channel 2 j 

I ^ POWER SAVE FRAME = 480mS for TDMA channel 1 \ ^ 



TSCC 
Outbound 



2 


1 


2 


1 


2 


1 


2 


1 


2 


1 


2 


1 


2 


1 


2 


1 


2 1 


1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 




PS_Counter=n [Olg] PS_Counter=n [lOg] PS_Counter=n [llg] 



[OO2] 



Figure 6.24: Power Save Frame Structure 

The power save frames are defined by the PS_Counter information element, a sub-set of the Common_Slot _Counter 
broadcast in the CACH. A sleeping MS shall wake for a designated power save frame. If the TSCC has a PDU or 
transaction for the sleeping MS, that PDU shall be queued until a designated power save frame is transmitted on the 
TSCC. MS or other entity that initiates a transaction to a sleeping MS (or group of MSs) shall be queued on the TSCC 
until the designated power save frame has been reached. Figure 6.24 shows a power save frame. For each logical 
channel there are eight slots available to signal MS during a designated power save frame. 

a) The MS and TSCC shall have previously synchronized a particular wake frame. 

b) The TSCC must know when a particular MS has woken and is able to receive signalling addressed to that MS. 
If several MSs are in a fleet and are party to a talkgroup call, all MSs in that particular talkgroup may share the 
same wakeup frame. The way in which the TSCC manages the power save and allocates particular wakeup 
frames is not prescribed in the present document. 

c) Different MSs sharing a common TSCC may have differing power save and the TSCC/MSs must be able to 
deal with this. 
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d) The Short LC that carries the Power Save Counter does not have to be continuously transmitted. When MS 
have received a Power Save Short LC they are able to calculate power save frames from that point. MS may 
then refresh by occasional appropriate short LC PDUs. 



6.4.7.2 



Power Save Procedures 



6.4.7.2.1 



Basic Power Save Procedures 



For a MS to activate power save, it registers with the TSCC. In the registration service request the MS may ask for 
power save it wishes to employ, by sending a non-zero three bit PowerSave_RQ information element with a number 
between 1 and 7. A registration service request with a zero PowerSave_RQ indicates that no power save is required or a 
previous power save is cancelled. The TSCC responds positively if it supports power save for that request, with a 
Powers ave_Off set information element (length 7) in the range to 1, to 3, to 7, to 15, to 31, to 63 or to 127. 

Table 6.11 : Power Save information elements during MS registration 



Power Save 


PowerSave RQ 


PowerSave Offset 


OFF 








1:2 


1 


Otol 


1:4 


2 


0to3 


1:8 


3 


0to7 


1:16 


4 


0to15 


1:32 


5 


0to31 


1:64 


6 


0to63 


1:128 


7 


to 127 



A PowerSave_RQ=l indicates the MS shall sleep for one Power Save Frame and awake for the second. A "2" indicate 
1 awake and 3 sleeping. A "3" indicates 1 in 8 awake and so on. In this example the greatest power save would be "7" 
indicating 1 in 128 awake as illustrated in table 6.11. 

The TSCC responds with an acknowledgement containing a PowerSave_Offset information element (the 
Responsejnfo information element in the acknowledgement PDU) that indicates the power save frame number that the 
TSCC will send signalling to that particular MS. The TSCC may therefore average out signalling across all power save 
frames for differing fleets (or differing talkgroups). The frame number is read by the MS and a mask applied according 
to the power save request. The answer gives the power save frame number for that power save value asked for in the 
registration request. The MS can then calculate when to wake for incoming traffic. 

EXAMPLE: A MS requests a power save of 4 by setting the value of PowerSave_RQ = 2 in the registration 
service request. The TSCC responds with Powersave_Offset = 2. 

The PS_Counter is counting up continuously. Suppose the PS_Counter at this moment = 65 Decimal- 



Table 6.12: Power Save Example - MS state 



PS Counter 


Count 


Mask Counter with PowerSave RQ 








65 


OIOOOOI2 



















1 


66 


010 001 O2 
















1 





67 


01000112 
















1 


1 


68 


01001002 













1 








69 


01001012 













1 





1 


70 


01001102 













1 


1 
























MS state 



Sleep 



Wake 



Sleep 



Sleep 



Sleep 



Wake 



Table 6.12 shows how a TSCC determines when a MS is awake. The TSCC applies a mask of length PowerSave_RQ. 
In this example the mask leaves two bits. When the masked PS_Counter equals the PowerSave_Offset the TSCC may 
signal the MS. 
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MS can sample the CACH at any time, read the Common_Slot Counter and determine when the wake frame will be 
transmitted. The MS may then sleep until a point at which its wake frame is scheduled. A PDU addressed to the MS by 
its individual address shall cause the MS to awaken for T_Awake seconds. Each MS individually addressed or 
applicable talkgroup address PDU transmitted on the TSCC or MS shall refresh T_Awake. If no PDUs have been 
transmitted or received by the MS when T_Awake expires the MS shall return to its sleeping state retaining its previous 
power save settings. 

If an MS awakes and receives an applicable C_AHOY PDU that will result in a payload channel being assigned, the MS 
shall stay awake for a time T_Pending for the Channel Grant PDUs to be transmitted. When that call is completed and 
the MS returns to the TSCC, the MS shall wait for T_Awake seconds and then return to the sleeping state. 

If while awake, the MS receives a C_MOVE PDU, the MS shall retain its T_Awake timer and return to its sleeping 
state after T_Awake expires, unless the move to the replacement TSCC causes the MS to re-register when new power 
save information elements shall be exchanged. 

6.4.8 Authentication Procedures 

Authentication is a procedure to verify that a MS (or TSCC) is genuine. The procedures rely on a key that is shared 
between an individual MS and the TS. When authenticating an MS, a convenient point for applying the authentication 
procedure is during MS registration. When a MS attempts to register by random access, the TSCC sends a random 
number in a C_AHOY PDU (the challenge). The MS calculates the response to the challenge, using a key using a 
standard algorithm (RC4). 
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Figure 6.25: Challenge and Response Authentication 

Figure 6.25 shows the mechanism. The MS calculates the response to the challenge. The TSCC uses the same algorithm 
and the same K,RAND values as the MS. The TSCC then compares the expected response with the actual response. If 
the responses match then the authentication is considered successful. 



6.4.8.1 



Key Management 



A 56 bit authentication key (K) is programmed into each MS. Key generation is specific to each manufacturer and not 
specified in the present document. The (K) of each MS is also programmed into the TS. (K) is intended to be valid for 
the lifetime of the MS, but if (K) is compromised for a particular MS, a manufacturer may choose to re-program the key 
(K) both in the MS and in the network management. 

NOTE: A compromised key only affects one MS and not the entire system. 



6.4.8.2 



Authentication Procedures for the TSCC to authenticate a MS 



The TSCC challenges an MS by transmitting a C_AHOY PDU to an individual MS address and information elements 
as illustrated in table 6.13. 

If the C_AHOY is transmitted as part of the registration procedure, the Service_Options_Mirror is set to the 
Service_Options from the C_Rand PDU. 

If the C_AHOY is transmitted in response to call set-up request, the Service_Options_Mirror is set to the 
Service_Options from the C_Rand PDU. 
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If the C_AHOY is transmitted as an authentication poll from the TSCC (and unconnected with a registration procedure) 
the Service_options_Mirror shall be set to 000 OOOO2. 

Table 6.13: C_AHOY information elements for authentication challenge 



Service_Options_Mirror 


7 




Service_Kind_Flag 


1 


O2 


Ambient Listening Service 


1 


O2 - Not Applicable 


IG 


1 


O2 - Target address is an individual MS address 


Appended_Blocks 


2 


OO2 


Service_Kind 


4 


IIIO2 


Target address 


24 


Address of Challenged MS 


Source Address or Gateway 


24 


Authentication challenge value 



6.4.8.3 



Authentication Procedures for the MS 



If an MS receives an applicable C_AHOY PDU it shall pass the authentication challenge value to the authentication 
algorithm. The result from this algorithm is a 24 bit authentication result. That is transmitted to the TSCC by a 
C_ACKU PDU. 

Table 6.14: Authentication response elements 



Responsejnfo 


7 


value 


Reason Code 


7 


0100 OIOO2 - Message Accepted 


Reserved 


1 


O2 


Target address 


24 


authentication challenge response 


Additional Information (Source Address) 


24 


MS individual address that is transmitting the acknowledgement 



6.4.9 MS Stun/Revive 

MS may be denied access to certain Tier III services using the stun mechanism. If a MS has been disabled by a stun 
procedure, the MS may not request nor receive any user initiated services on the network that performed the procedure. 
However hunting and registration, authentication, stun / revive and registration services shall remain active. 

While an MS is stunned, it may also retain the NMEA (lEC 61162-1 [8]) polling service described in clause 6.6.5.1.5. 

In the present document, MS shall only be stunned/revived from a TSCC gateway STUNI as described in 
clause 6.4.9.1.1. 



6.4.9.1 
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Figure 6.26: MS Stun/Revive Procedure 

Figure 6.26 shows the mechanism where the MS does not demand authentication prior to the stun. 

a) The TSCC sends a C_AHO Y from STUNI at "A" . 

b) MS makes an appropriate acknowledgement at "B". 
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6.4.9.1 .1 Stun / Revive procedures for the TSCC 

The TSCC transmits a C_AHOY with the information elements as illustrated in table 6.15. 

Table 6.15: C AHOY information elements for Stun/Revive 



Service_Options_Mirror 


7 


000 OOOO2 


Service_Kind_Flag 


1 


02to stun, l2to revive 


Ambient Listening Service 


1 


O2 - Not Applicable 


IG 


1 


O2 - PDU addressed to an individual MS address 


Appended_Blocks 


2 


OO2 


Service_Kind 


4 


Supplementary Service - 11 01 2 


Target address 


24 


Individual Address of Called MS 


Source Address or Gateway 


24 


STUNI (see clause A.4) 



a) If the response is C_ACKU(Reason=Message_Accepted) the TSCC shall interpret the acknowledgement that 
the stun/revive procedure was successful. 

b) If the response is C_NACKU (Reason=MSNot_Supported) the TSCC shall interpret the acknowledgement that 
stun/revive is not supported by the MS. 



6.4.9.1.2 



Stun / Revive procedures for the IVIS 



If the MS receives an applicable stun/revive C_AHO Y but the MS does not support stun / revive it shall respond with 
C_NACKU(Reason=MSNot_Supported). 

If the MS receives an applicable stun/revive C_AHO Y and the MS supports stun / revive it shall examine the 
Service_Kind_Flag, call the appropriate stun or revive procedure and respond with C_ACKU 
(Reason=Message_Accepted) . 



6.4.9.2 



MS Stun/Revive with authentication 
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Figure 6.27: MS Stun/Revive with Authentication 

Figure 6.27 shows the mechanism where the MS demands authenticates the TSCC prior to the stun: 

a) The TSCC sends a C_AHOY from STUNI at "A" to stun the MS. 

b) The MS makes its authentication challenge at "B" by transmitting a C_ACVIT PDU. This Ackvitation sent by 
the MS is the acknowledgement to the initial C_AHOY from the TSCC. 

c) At "C" the TSCC sends the challenge response to the MS. The MS authenticates the challenge response. If the 
challenge response is ratified by the MS, the MS stuns/revives and sends 

C_ACKU(Reason=Message_Accepted. If the challenge response fails authentication, the MS shall send 
C_NACKU(Reason=Recipient_Refused) ("D"), and the MS shall not stun. The TSCC may repeat step "C" if a 
response is not successfully received at "D". 

d) The final acknowledgement is sent to the TSCC. 
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6.4.9.2.1 Stun / Revive procedures with authentication for the TSCC 

The TSCC transmits a C_AHOY with the information elements as illustrated in table 6.15. 

If the MS response is a C_Ackvitation (Target Address=AUTHI, Source Address=challenge value) the TSCC shall 
interpret that PDU as an acknowledgement and that the TSCC is being challenged that the TSCC is authentic. 

The TSCC shall send the response C_ACKD(Reason=Message_Accepted) with the information elements as illustrated 
in table 6.16. 

Table 6.16: Authentication Response Elements 



Response Info 


7 


value 


Reason Code 


8 


OIIOOOOO2 


Reserved 


1 


O2 


Target address 


24 


authentication challenge response 


Additional Information (Source Address) 


24 


AUTHI (see clause A. 4) 



When the TSCC response to the challenged has been transmitted to the MS, the MS shall send a final 
acknowledgement: 

a) If the final acknowledgement transmitted by the MS is C_ACKU(Message_Accepted) the TSCC shall identify 
that the stun/revive procedure was successful. 

b) If the final acknowledgement transmitted by the MS is C_NACKU(Recipient_Refused) the TSCC shall 
identify that the authentication was unsuccessful. 



6.4.9.2.2 



Stun / Revive procedures with authentication for the IVIS 



If the MS receives an applicable stun/revive C_AHO Y but the MS does not support stun / revive it shall respond with 
C_NACKU(Reason=MSNot_Supported). 

If the MS receives an applicable stun/revive C_AHOY the MS shall authenticate the TSCC by transmitting a 
C_Ackvitation with information elements as illustrated in table 6.17. 

Table 6.17: C_Ackvitation - MS challenges the TSCC 



Service_Options_Mirror 


7 


0000 OOO2 


Service_Kind_Flag 


1 


02to stun, l2to revive 


Reserved 


2 


O2 


Appended_Blocks 


2 


OO2 


Service_Kind 


4 


Supplementary Service - 11 01 2 


Target address 


24 


AUTHI (see clause A.4) 


Source Address or Gateway 


24 


Authentication Challenge Value 



The MS shall examine the response to the authentication challenge and validate the authentication. The MS shall then 
send a final acknowledgement C_ACKU(Reason=Message_Accepted) if the authentication was successful or 
C_NACKU(Reason= Recipient_Refused) if the authentication was unsuccessful. 

If the MS supports stun / revive it shall then examine the Service_Kind_Flag, and call the appropriate stun or revive 
procedure. 
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Table 6.18: Final Acknowledgement 



Responsejnfo 


7 


value 


Reason Code 


8 


Message_Accepted - 0100 OIOO2 


Recipient_Refused - 0001 OIOO2 


Reserved 


1 


O2 


Target address 


24 


AUTHI (see clause A.4) 


Additional Information (Source Address) 


24 


MS Individual Address 



6.4.10 MS Kill 

MS may be completely and permanently disabled using the kill mechanism. If a MS has been killed by a kill procedure, 
the MS shall lose all DMR functionality. An MS may not be revived from the kill state by any AI generated message. 

In the present document, MS shall only be killed from a TSCC gateway KILLI. 
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Figure 6.28: MS Kill (with Authentication) 

Figure 6.28 illustrates the mechanism for MS kill: 

a) The TSCC sends a C_AHOY from KILLI at "A" to kill the MS; 

b) The MS acknowledges the C_AHOY in the next slot and makes its authentication challenge at "B" by 
transmitting a C_ACVIT PDU. This Ackvitation sent by the MS is the acknowledgement to the initial 
C_AHOY from the TSCC; 

c) At "C" the TSCC sends the challenge response to the MS. This response may be delayed in accordance with 
the random access timing defined in clause 6.2. LL4^ The MS authenticates the challenge response. If the 
challenge response is ratified by the MS, the MS sends C_ACKU(Reason=Message_Accepted). Following the 
acknowledgement the MS disables all DMR functionality; 

d) If the challenge response fails authentication, the MS shall send C_NACKU(Reason=Recipient_Refused) 
("D"), and the MS shall not kill. The MS may repeat step "B" if the challenge response is not successfully 
received by the TSCC at "C". 

NOTE: A situation may exist where the final acknowledgement C_ACKU was sent by the MS (and the MS 

disabled all functionality) but the acknowledgement was not received by the TSCC. In this case, repeating 
the kill procedure from step "A" would not result in any response from the MS. The TSCC should be able 
to deal with this situation. 
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6.4.1 0.1 Kill procedures with authentication for the TSCC 

The TSCC transmits a C_AHOY with the information elements as illustrated in table 6.19. 

Table 6.19: C AHOY information elements for Kill 



Service_Options_Mirror 


7 


000 OOOO2 


Service_Kind_Flag 


1 


O2 


Ambient Listening Service 


1 


O2 - Not Applicable 


IG 


1 


O2 - PDU addressed to an individual MS address 


Appended_Blocks 


2 


OO2 


Service_Kind 


4 


Supplementary Service - 11 01 2 


Target address 


24 


Individual Address of Called MS 


Source Address or 
Gateway 


24 


KILLI (see clause A.4) 



If the MS response is a C_Ackvitation (Target Address=KILLI, Source Address=challenge value) the TSCC shall 
interpret that PDU as an acknowledgement and that the TSCC is being challenged that the TSCC is authentic. 

The TSCC shall send the response C_ACKD(Reason=Message_Accepted) with the information elements as illustrated 
in table 6.20. 

Table 6.20: Authentication Response Elements 



Responsejnfo 


7 


value 


Reason Code 


8 


OIIOOOOO2 


Reserved 


1 


O2 


Target address 


24 


authentication challenge response 


Additional Information 
(Source Address) 


24 


KILLI (see clause A.4) 



When the TSCC response to the challenge has been transmitted to the MS, the MS shall send a final acknowledgement. 

a) if the final acknowledgement transmitted by the MS is C_ACKU(Message_ Accepted) the TSCC shall identify 
that the kill procedure was successful; 

b) if the final acknowledgement transmitted by the MS is C_NACKU(Recipient_Refused) the TSCC shall 
identify that the kill was unsuccessful. 

6.4.1 0.2 Kill procedures with authentication for the MS 

If the MS receives an applicable kill C_AHO Y but the MS does not support kill it shall respond with C_NACKU 
(Reason=MSNot_Supported). 

If the MS receives an applicable kill C_AHOY the MS shall authenticate the TSCC by transmitting a C_Ackvitation 
with information elements as illustrated in table 6.21. 

Table 6.21 : Authentication Response Elements 



Service_Options_Mirror 


7 


0000 OOO2 


Service_Kind_Flag 


1 


O2 


Reserved 


2 


O2 


Appended_Blocks 


2 


OO2 


Service_Kind 


4 


Supplementary Service - 1 101 2 


Target address 


24 


KILLI (see clause A.4) 


Source Address or 
Gateway 


24 


Authentication Challenge Value 
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The MS shall examine the response to the authentication challenge and validate the authentication. The MS shall then 
send a final acknowledgement C_ACKU(Reason=(Message_Accepted) if the authentication was successful or 
C_NACKU(Reason= Recipient_Refused) if the authentication was unsuccessful (illustrated in table 6.22). 

Table 6.22: Final Acknowledgement 



Response Info 


7 


Value 


Reason Code 


8 


Message_Accepted - 0100 OIOO2 


Recipient_Refused - 0001 OIOO2 


Reserved 


1 


O2 


Target address 


24 


KILLI (see clause A.4) 


Additional Information 
(Source Address) 


24 


MS Individual Address 



6.4.1 1 IP Connection Advice 

For a MS to forward an IP connection address to the Tier III network, the MS makes use of the registration procedures 
specified in clause 6.4.4 to register (or repeat the registration) with the TSCC (see note). In the registration service 
request the Service Options contain the IP_Inform information element. If the MS registers with the IP_Inform=l2, the 
TSCC invokes the UDT procedures and sends a AHOY to ask the MS for an IP connection address. 

a) the MS may repeat this procedure if it has additional IP addresses to send to the system; 

b) the MS may delete an IP connection by sending a registration service deregister with Reg_Dereg=02 and 
IP_Inform=l2 (This combination of information elements does not deregister the MS). 

If the TSCC has the IP addresses for MS registered, the TSCC is able to cross reference the IP address with the MS 
individual address if the MS has activated power save. 

The PDU exchange to add or subtract an IP connection and request power save is illustrated in figure 6.29. 

NOTE: The MS may already be registered with the system. Repeating the registration procedure is however a 
convenient mechanism to convey IP connection addresses. 
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Figure 6.29: MS IP Connection Advice 

Figure 6.29 shows a MS registration procedure with the optional steps "B" and "C": 

a) at "A" the MS makes a random access registration attempt with IP_Inform=l2; 

b) the AHOY PDU at "B" is the acknowledgement to the random access and asks the MS to respond with the IP 
connection advice. The timer TNP_Timer timer is started; 

c) "C" is the MS response using the UDT IP format; 

d) the final C_ACKD or C_NACKD is sent on the TSCC to the MS. 
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6.4.1 1 .1 IP Connection Advice procedures for the MS 

When a MS determines that it wished to advise a change of IP connection (i.e. add or delete an IP address), it shall 
attempt to do so by the registration procedures specified in clause 6.4.4. The indication that a registration request is for 
the purpose of IP connection advice is the information element IP_Inform=l2 in the Service Options, (see table 6.9). 

Valid TSCC responses to the random access request are - C_WACKD(Reason=Wait) more signalling to follow, 
C_NACKD(Reason=Reg_Refused), C_NACKD(Reason=Reg_Denied), or C_AHOY(Source Address or 
Gateway=IPI). If the TSCC response is an acknowledgement, the PDU destination address shall be MS ID and the 
Source address shall be REGI. 

6.4.1 1.1.1 Registration Attempt Times Out 

If the MS times out from waiting for further signalling for IP connection request and the MS was not previously 
registered, (expiry of timer TNP_Timer), it shall enter the TSCC acquisition procedures. If the MS was previously 
registered, the MS shall return to the TSCC idle state. 

6.4.1 1 .1 .2 No answer response received after the maximum number of random access 
attempts 

If no response is received within WAIT+1 slots after the MS has transmitted NRand_NR random access attempts, the 
MS shall make no consequential changes to its IP connection record. 

6.4.1 1 .1 .3 IVIS response to C_AHOY inviting the IVIS to send an IP address 

The MS shall send the IP address using the UDT mechanism. The response shall be a HEAD+appended data. The 
HEAD information elements shall be UDT_Format=01 IO2, UAB=002 for IPV4 or UAB=0l2 for IPV6, SF=l2, 
Target_address=MS ID, Source_address=IPI. 

6.4.1 1 .1 .4 Final acknowledgment to IP connection advice received by the calling MS 

The MS may receive C_ AC KD=Reg_ Accepted. In that case the MS shall assume that the IP connection advice was 
accepted by the TSCC. 

If the TSCC refuses the IP connection advice the MS may receive C_NACKD(Reason=IP_Connection_f ailed). In that 
case the MS shall assume that the IP connection advice has not been accepted by the TSCC. No change in the IP 
connection record shall be made. 

6.4.1 1 .2 IP Connection Advice procedures for the TSCC 

If the TSCC receives a random access registration request attempt with IP_Inform=l2, and the TSCC wishes to accept 

an IP connection address, it shall transmit a C_AHOY from IPI inviting the MS to send the IP address using the UDT 
mechanism. 

The TSCC may transmit any of the acknowledgements C_WACKD(Reason=Wait) more signalling to follow, 
C_NACKD(Reason=Reg_Refused), C_NACKD(Reason=Reg_Denied), or C_AHOY(Source Address or 
Gateway=IPI). If the TSCC response is an acknowledgement the PDU destination address shall be MS ID and the 
Source address shall be REGI. 

The TSCC may not be able to accept the IP address. In that case the TSCC shall send 
C_NACKD(Reason=IP_Connection_f ailed). The TSCC shall not change the IP connection record. 
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6.4.12 MS Radio Check 

If a TS wishes to check if an MS is Hstening, a simple MS radio check may be conducted at any time. 
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Figure 6.30: MS Radio Check 

Figure 6.30 illustrates the message exchange for a radio check on the control channel. An MS Radio Check may also be 
conducted on the traffic channel. The TSCC (or TS) transmits a C_AHOY with the information elements as illustrated 
in table 6 23. 

Table 6.23: C AHOY information elements for MS Radio Check 



Service_Options_Mirror 


7 


000 OOOO2 


Service_Kind_Flag 


1 


O2 Not Applicable 


Ambient Listening Service 


1 


O2 - Not Applicable 


IG 


1 


O2 Target address is a MS individual ID 


1 2 Target address is a talkgroup 


Appended_Blocks 


2 


OO2 


Service_Kind 


4 


Registration - IIIO2 


Target address 


24 


Polled MS 


Source Address or 
Gateway 


24 


TSCI (see clause A.4) 



The MS shall send the response C_ACKU(Reason=Message_Accepted) with the information elements as illustrated in 
table 6.24. 

Table 6.24: MS Radio Check Response Elements 



Responsejnfo 


7 


value 


Reason Code 


8 


OIOOOIOO2 


Reserved 


1 


O2 


Target address 


24 


TSCI 


Additional Information 
(Source Address) 


24 


MS individual address 



Whether the MS was polled by its individual address or a talkgroup, the C_ACKUD Source Address shall always be the 
MS individual address. 

6.4. 1 3 Supplementary_User Data Service 

The inbound supplementary_user data service may be invoked as part of another service. It enables supplementary_user 
data to be transferred between entities as part of a voice or data call setup. The inbound phase illustrated in figure 6.31 
is invoked by a C_AHOY (Source address=SUPLI) addressed to the MS. The MS response is a UDTHU(Source 
address=MS ID, Target_address=SUPLI) + one to four appended data blocks. 
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Figure 6.31 : Supplementary_User Data Service inbound 

The outbound phase illustrated in figure 6.32 is composed of a UDTHD(Source address=SUPLI, Target_address=MS 
ID) + one to four appended data blocks. If the MS accepts the supplementary_user data the acknowledgement shall be a 
C_ACKU(message_accepted) (Source_address=MS ID, Target_address=SUPLI). 
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Figure 6.32: Supplementary_User Data Service outbound 

A complete example of a voice call invoking supplementary _user data is illustrated in figure 6.37. 

6.4.14 MS Power Control and Transmitter Pre-emption Control 

Closed loop power control is a method by which a TS is able to dynamically control the transmitter output power of an 
MS. If a Tier III TS or MS supports this feature, the feature shall be implemented as described in this clause. 

A trunked network may employ a combination of MS that do and do not support this feature. In addition, it must be 
noted that this feature uses the Reverse Channel (RC) [5] and the RC may not always be available. The Tier III system 
shall be able to deal with this. 

The principle of power control is: 

• The TS measures the received signal strength of a transmitting MS, and compares the received value with two 
programmable thresholds. The thresholds are the upper limit for the received signal strength (L_Power_Hi) 
and the lower limit (L_Power_Low). If the received signal strength exceeds the threshold L_Power_Hi, the TS 
will send a decrease power PDU to the MS. If the signal strength is below the lower limit L_Power_Low, the 
TS will send an increase power control PDU to the MS. 

The principle of transmitter pre-emption control is: 

• Transmitter pre-emption control may be implemented to stop an MS transmission so that a new call of higher 
priority may use the channel. 



6.4.14.1 



Reverse Channel 



Both MS power control and MS transmitter pre-emption control use the Reverse Channel. The 1 1 bits of the Reverse 
Channel are subdivided into the RC SAP (5 bits) and the Commands (6 bits as illustrated in table 6.25. 
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Table 6.25: MS Reverse Channel information elements 
for Power Control and Transmitter Control 



Reverse Channel 


RCSAP 


Command 


Length 


Value 


Description 


Length 


Value 


Description 


5 


OOOO2 


Reserved 


6 






0001 2 


Power Control 


00 OOOO2 


Reserved 


00 0001 2 


Increase power by one step 


0000102 


Decrease power by one step 


00 0011 2 


Set power to highest 


0001002 


Set power to lowest 


0001012 

to 11 IIII2 


Reserved 


000102 


Pre-emption 
Control 


00 OOOO2 


Reserved 


00 0001 2 


Cease transmission immediately 


0000102 


Stop transmission at the end of the 
next voice frame 


0001012 

to 11 IIII2 


Reserved 


000112 

to 1 IIII2 


Reserved 






NOTE: The power step j 


5ize is manufacturer depender 


t. 





6.4.14.2 



Procedures for Power Control 



The RC repetition rate for power control shall be 360 ms. If MS receive a RC PDU with the RC SAP set to OOOI2, the 
MS shall examine the RC Command to adjust the transmit power setting. If the MS is transmitting at maximum power 
and receives an "increase power" RC Command, the MS shall retain its maximum power setting. Similarly, if the MS is 
transmitting at minimum power and receives a "decrease power" RC Command, the MS shall retain its minimum power 
setting. 

6.4.14.3 Procedures for Transmission Pre-emption Control 

MS may support transmission pre-emption control. The TS shall transmit one or more SAP RC PDUs with the RC SAP 
set to OOIO2 to cause the MS to cease transmission. The TS shall then monitor the channel to ascertain if the MS did 
cease transmission. Two options are permitted: 

• cease transmission immediately; 

• stop transmission at the end of the next voice frame. 

If the MS did not cease transmission, it may be that the MS did not successfully receive the RC PDU or the MS does 
not support the feature. The TS may repeat the RC PDU. 

6.5 Unified Data Transport IVIecJianism 

A Tier III network supports a wide range of services. To support these services, the transporting of data is a very 
common necessity. Although Short Data is a primary data service, there are many instances where data needs to be 
transported to support other services. (For example when a MS dials a PABX or PSTN destination, the dialled digits are 
uploaded to the TSCC.) Whether the data remains within the network or is used to support other services, the 
Supplementary Data Transfer Service may be invoked. To reduce the Tier III complexity, all data transport using the 
TSCC share a common method - the Unified Data Transport Mechanism. 
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a) Supplementary Data Transfer Service: 

1) inbound transport of destination addresses that are connected through system gateways; 

2) inbound transport of PSTN and PABX dialling digits from MS; 

3) inbound transport of IPV4/IPV6 addresses; 

4) inbound transport of MS NMEA (lEC 61 162-1 [8]) location information; 

6) outbound channel transport of remote addresses that are connected through system gateways; 

7) outbound channel transport of CLI information from PABX/PSTN networks; 

8) outbound channel transport of IPV4/IPV6 address information from IP networks; 

9) outbound channel transport of a Source Address in a number of standard and proprietary formats; 

10) outbound channel transport of NMEA (lEC 61 162-1 [8]) MS location; 

11) transport of supplementary_user data as part of another service. 

b) Short Data Transfer Delivery Service. 

c) Short Data Polling Service. 

d) Inbound transport of digits for the Call Diversion Service. 

The format for the data transfer is the same for transfers using the outbound channel and transfers using the inbound 
channel. The UDT employs the UDT type (UDT) PDU. The first block is the header as illustrated in figure 6.33. This 
block carries source and destination addresses, the format of the data being carried, and UDT Format that denotes the 
service being supported. Up to four Appended data blocks may follow the header to carry the data. All blocks of the 
UDT shall be transmitted consecutively. 



Ut>T HEADER 


m6 


5 1 4 3 2 1 


Octet Opg A 


RSVD FORMAT 


Octet 1 


SAP 1 UDT FORMAT 


Octet 2 


TARGET ADDRESS OR 
GATEWAy(24) 


Octet 3 


Octet 4 


Octet 5 


SOURCE ADDRESS OR 
GATEWAy(24) 


Octet 6 


Octet 7 


Octet 8 


PAD NIBBLE 1 1 UAB 


Octet9B3PF 


OPCODE 



Figure 6.33: UDT Header 

The UAB information element indicates the number of UDT blocks that are appended to this header. For a UDT 
addressed to an individual MS, the A information element denotes if a response to this multi-block UDT is expected. 
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Figure 6.34: A Short Data call using the UDT mechanism 

Figure 6.34 is just one example showing how the Short Data service makes use of the UDT mechanism. The Short Data 
employs a store and forward technique and the procedures are fully described in clause 6.6.4. 

However the UDT segments are highlighted to show the upload and download phases that are described in these 
clauses. In this example the MBC blocks consist of a Header + one appended block. 
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Figure 6.35: MS to PABX/PSTN Call using the UDT Mechanism 

Figure 6.35 illustrates a call set-up for a call from an MS to the PABX/PSTN. Calls to these destinations are 
characterized by the necessity of passing the dialled destination to the system. The UDT mechanism provides an 
unambiguous transfer. In this example the UDT consists of a Header + one appended block for up to 20 dialled digits. 
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Figure 6.36: Call from the PSTN/PABX using the UDT Mechanism 
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Figure 6.36 illustrates a further example of a call from the PSTN. The TSCC has elected to download the CLI 
information to the recipient as part of this call set-up. The Service_Kind information element is passed in the header 
therefore the recipient MS knows the call is inbound and the call is from the PSTN. Since the Service_Kind is known to 
the recipient, a secondary feature of the UDT mechanism is that it may serve as a radio check. Only if the MS responds 
with a positive (C_ACKU) acknowledgement does the call mature. 
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Figure 6.37: UDT mechanism carrying supplementary data 

Figure 6.37 shows how supplementary_user data may be carried as part of a call. MS(A) wishes to send its GPS 
position as part of a voice call set-up. MS therefore elects to indicate that supplementary_user data is available in the 
Service_Options information element by setting Supplementary_Data=l2. The TSCC uploads the supplementary_user 
data and passes the data to the recipient. The UDT download/acknowledgement also serves as the radio check. 

6.5.1 Format of the appended data 

The format of the appended data is specified in annex B. The standard formats are: 

a) Address format - the appended block(s) contain DMR addresses. 

b) Binary Format - the appended block(s) contain binary data. 
BCD format - the appended blocks contain digit coded. 

7 bit text coded - the appended data is text coded using ISO 7 bit character set (ISO/IEC 646 [11]). 

8 bit character coded - the appended data is character coded using ISO 8 bit character set (ISO/IEC 8859 [12]). 



c) 
d) 
e) 
f) 



NMEA (lEC 61 162-1 [8]) location format - the appended data is coded specifically for NMEA 
(lEC 61162-1 [8]) position data. 

g) 16 bit Unicode format [9]. 

6.5.1.1 UDT Block Structure 

The UDT block structure is described in TS 102 361-1 [5], clause 8.2.2.3. 

6.5.1 .2 UDT Content for Services Carried on the Outbound channel 

The UDT outbound channel mechanism may be invoked as part of a DMR service. The UDT head PDU contains all 
parameters for a MS or talkgroup UDT. The data to be downloaded is held in the TSCC and the information elements 
formed as table 6.26. 
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Table 6.26: UDT Outbound channel information elements 



UDT Outbound channel Mechanism 






UDT Outbound channel PDUs 




Service 


Operation 


Service 
Kind 


Supple 
mentary 

Data 

Flag 


UDT- 
Format 


UDT_ 
Response 


Target 

address or 

gateway 


Source or 
gateway 
Address 


MS Response 
to Head+Data 


Voice Call 
from PSTN 
to Individual 
MS 


Send CLI 
information 
from PSTN 


Individual 

Voice Call 

Service 

(0001 2) 


I2 


BCD 
(001 O2) 


O2 option 


Destination 
MS Address 


PSTNI 


No 


1 2 option 


ACK, NACK 


Voice Call 
from PABX 
to Individual 
MS 


Send CLI 
information 
from PABX 


Individual 

Voice Call 

Service 

(0001 2) 


I2 


BCD 
(001 O2) 


O2 option 


Destination 
MS Address 


PABXI 


No 


1 2 option 


ACK, NACK 


Voice Call 
from PSTN 
to Talkgroup 


Send CLI 
information 
from PSTN 


Talkgroup 

Voice Call 

Service 

(001 O2) 


I2 


BCD 
(001 O2) 


O2 


Destination 
Talkgroup 


PSTNI 


No 


Voice Call 
from PABX 
to Talkgroup 


Send CLI 
information 
from PABX 


Talkgroup 

Voice Call 

Service 

(001 O2) 


I2 


BCD 
(001 O2) 


O2 


Destination 
Talkgroup 


PABXI 


No 


Voice Call 
from MS to 
Individual 
MS 


Send NMEA 
information 
from Source 
MS 


Individual 

Voice Call 

Service 

(0001 2) 


I2 


NMEA 

formatted 

(01 01 2) 


O2 option 


Destination 
MS Address 


Source MS 


No 


1 2 option 


ACK, NACK 


Voice Call 
from MS to 
Individual 
MS 


Send 

supplementary 
text PDU as 
part of call 
setup 


Individual 

Voice Call 

Service 

(0001 2) 


I2 


7 bit txt 
(0011 2) 


O2 option 


Destination 
MS Address 


Source MS 


No 


1 2 option 


ACK, NACK 


Short Data 
call from MS 
to MS 


Short Data 

Outbound 

Phase 


Indiv" Short 

Data 

(OIOO2) 


O2 


UDT_For 
mat 


I2 


Destination 
MS Address 


Source MS 


ACK, NACK 


Short Data 
call from 
Dispatcher to 
MS 


Short Data 

Outbound 

Phase 


Indiv" Short 

Data 

(OIOO2) 


O2 


UDT_For 
mat 


I2 


Destination 
MS Address 


DISPATI 


ACK, NACK 


Send 
Diverted 
address to 
caller 


See clause 6.6.7 
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The information elements of the PDUs in the UDT Header information elements are summarized: 



UDT_Format 


specifies the format of the data transported in the appended data blocks of the 
multi-block UDT 




if the UDT outbound is the second phase preceded by a UDT Inbound, the 
UDT Format shall be copied from the UDT Inbound Header 


Appended Blocks 


specifies the number of appended data blocks concatenated to the header 


Supplementary_Flag 


specifies if: 

- this UDT Header is carrying the data for a user initiated service (e.g. Short 
Data Delivery); or 

- this UDT Header is carrying supplementary_user data, supporting another 
service 


UDT Response 


specifies if the TSCC is expecting a response from this UDT download: 




- if the UDT download is addressing an individual MS then: 

* if the UDT download is supporting an Supplementary _User Data 
transfer then this information element may be set or clear 

* for the Short Data Service then this information element shall be set to ^2 

- response expected 

- if the UDT download is addressing a talkgroup then: 

* the UDT information element shall be set to O2 - response not expected 


Service Kind 


specifies the service being supported by the UDT mechanism 


Target address or Gateway 


individual MS address or Talkgroup or All Unit 


Source_address or gateway 


source MS address for a service originating from an MS 
PABXI for a service originating from a PABX extension 
PSTN! for a service originating from the PSTN 
IPI for a service originating from an IP network 



6.5.1.3 



UDT Mechanism for the Inbound channel 



The UDT inbound channel mechanism is invoked as part of a DMR service. The UDT head PDU contains all 
parameters for the UDT. The data to be uploaded is set as table 6.27. This table is not exhaustive and many other 
arrangements are possible to support Tier III services. 
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Table 6.27: UDT Inbound channel information elements 



UDT Inbound channel Mechanism 








UDT Inbound channel information elements 


Service 


Operation 


Service_Kind 


Supple 
mentary 

Flag 


Format 


UDT 
Response 


Target 

address or 

gateway 


Source 

Address or 

gateway 


Voice Call 
from 

Individual 
MS to PSTN 


Send PSTN 
dialling 
information 
from MS 


Individual 

Voice Call 

Service 

(0001 2) 


I2 


BCD) 
(0001 2) 


O2 (N/A) 


PSTNI 


MS Address 


Voice Call 
from 

Individual 
MS to PABX 


Send PABX 
dialling 
information 
from MS 


Individual 

Voice Call 

Service 

(0001 2) 


I2 


BCD 
(0001 2) 


O2 (N/A) 


PABXI 


MS Address 


Voice Call 
from MS to 
Individual 
MS 


Inbound NMEA 
information 
from Source 
MS 


Individual 

Voice Call 

Service 

(0001 2) 


I2 


NMEA 
(01 01 2) 


O2 (N/A) 


Destination 
MS 


MS Address 


Short Data 
call from MS 
to MS 


Short Data 
Inbound Phase 


Indiv" Short Data 
(OIOO2) 


O2 


UDT_For 
mat 


O2 (N/A) 


Destination 
MS 


Source MS 


NMEA 
polling from 
a gateway 


Short Data 
Inbound Phase 


Short data 

polling serv" 

(01 11 2) 


O2 


NMEA 
(01 01 2) 


O2 (N/A) 


Destination 
MS 


ATSCC 
Gateway 


Call 

Diversion 

Service 


Diversion 
Inbound phase 


Call Diversion 

serv" 

(OIIO2) 


O2 


value 


O2 (N/A) 


DIVERTI 


MS 


Authenticatio 
n 


Inbound MS 
Authentication 


Authentication 
serv" 


O2 


AUTH 
(01 11 2) 


O2 (N/A) 


AUTHI 


MS 


IP Address 
registration 


Inbound IP 
address 


Registration 
Service 


I2 


IP 

(OIIO2) 


O2 (N/A) 


TSI 


MS 



The Key protocol aspects of the information element settings in the UDT Header feature elements are: 



UDT_Format 


specifies the format of the data transported in the appended data blocks of the 
multi-block UDT 


Appended_Blocks 


specifies the number of appended data blocks concatenated to the header 


Supplementary_Flag 


specifies if: 

- this UDT Header is carrying the data for a user initiated service (Short Data, 
Data Polling); or 

- this UDT Header is carrying supplementary_user data, supporting another 
service 


UDT Response 


N/A 


Service Kind 


specifies the service being supported by the UDT mechanism 


Target _address or Gateway 


target MS address 

PABXI for a service to a PABX extension 

PSTNI for a service to the PSTN 

IPI for a service to an IP network 


Source_address or gateway 


Source MS address or gateway 



6.6 Call procedures 



Access to Tier III Services from MS shall be by random access using the random access protocol described in 

clause 6.2. The C_RAND CSBK random access PDU contains all parameters necessary to signify the particular Tier III 

service requested. 

a) Individual Voice Call Service. 

b) Talkgroup Voice Call Service. 
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c) Individual Packet Data Call Service. 

d) Packet Data Call Service for a talkgroup. 

e) Individual Short Data Delivery Service. 

f) Talkgroup Short Data Delivery Service. 

g) Call Diversion Service. 

h) Short Data Polling (from an MS) Service. 

i) Include Individual Call Service (Payload Channel only). 

j) Include Talkgroup Call Service (Payload Channel only). 

k) Registration Service (see clause 6.4). 

1) Answer Call Service. 

m) Cancel Call Service. 

To support these services the Tier III protocol implements a supplementary data transport mechanism whereby data 
may be carried between entities to support or enhance other services. 

For MS call to an MS, talkgroup or All-MS, the full source and destination address is provided in the C_RAND PDU so 
a single-part call set-up procedure shall be invoked. For MS calls to destinations connected through a gateway (such as 
PSTN), a multi-part call procedure sets an appropriate gateway address as the destination in the C_RAND PDU. The 
TSCC then demands the extended_addressing information from the calling MS using the Unified Data Transport 
Service (see clause 6.5). 
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Figure 6.38: Example of Multi-part call procedure 

Figure 6.38 shows an example of a call to a PABX extension: 

a) "A" is the random access C_RAND PDU. The destination address is set to PABXI indicating a multi-part call 
setup for a call service to the PABX. 

b) "B" is a C_AHOY PDU from PABXI to ask the calling MS for the PABX extension digits. 

c) The UDT inbound channel "C" contains a multi-block UDT consisting of a header and an appended data block 
containing the PABX extension digits. 

d) The TSCC sends the Channel Grant PDUs to the MS at "D". 

The procedures for Voice and packet data are specified in clauses 6.6.2 and 6.6.3 respectively. The procedures include: 

e) Call Setup: 

1) random Access Call Request; 

2) possible AHOY/UDT procedure to provide extended addressing for calls through gateways; 

3) availability check to called party; 

4) Channel Grant. 
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f) Call Management on the payload channel: 

1 ) call maintenance ; 

2) call clear-down. 

6.6.1 Procedures common to Voice calls and Packet Data Calls 

6.6.1 .1 MS Availability Checks 

6.6.1 .1 .1 Availability of calling MS 

A MS requests a call service by transmitting a random access service request. While the call set-up is in progress, the 
TSCC may check that the requesting MS is still in radio contact at any time by sending a C_AHOY PDU addressed to 
it. The C_AHOY PDU demands a response from the calling MS. 

6.6.1 .1 .2 Availability of called party as part of a call 

The TSCC may check that the called party is in radio contact either during a call set-up by sending an AHOY PDU. If 
the message is sent by the TSCC the PDU is a C_AHOY. If the message is sent by a TS on a payload channel the PDU 
is a P_AHOY. A called party check may be addressed to an individual MS or a talkgroup. If the called party check is 
addressed to an individual MS, that MS shall respond with an appropriate acknowledgement. If the called party check is 
addressed to a talkgroup, all members of the talkgroup shall send an appropriate acknowledgement. In this case, one or 
a multiplicity of MSs may acknowledge this message. It is unlikely that the TS could recover any particular message 
but this is a useful feature because it identifies to the TS that at least one talkgroup is listening on that channel. 

6.6.1 .1 .3 General MS radio check 

In addition to the Calling MS and called party radio checks sent as part of a call set-up, the AHOY message may be sent 
by the TS at any time to check if a MS address or talkgroup is listening. The simple radio check AHOY is described in 
clause 6.4.12. 

6.6.1.2 Call Cancellation 

If a Voice call or Packet Call service request has been passed to the MS CC layer, and the call is cancelled before the 
Random Access PDU has been transmitted to the TSCC, the MS shall return to the idle state. 

If a MS has initiated a voice call service and the call has not matured (by the transmission of Channel Grant PDUs) the 
call may be cancelled by the calling party initiating a Call Cancel Service request. This is a random access service 
request (Service_Kind=l 1 1 12 Cancel Call Request). The TSCC response to a call cancel request shall be C_ACKD 
(Reason=Message accepted). 

6.6.1 .3 Acknowledgennents sent to calling MS 

From the point at which a MS has requested a particular service, the TSCC may send acknowledgement PDUs to 
indicate to the calling MS the progress of the service request. 

a) The TSCC may send PDUs that complete or terminate the call service request as follows: 

1) The TSCC may send C_NACKD to indicate to the calling MS that the call has failed. The C_NACKD 
PDU contains a Reason code to indicate to the caller why the service request failed. 

2) The TSCC may send a UDT header + appended UDT block to indicate that the call is diverted. From the 
TSCC perspective the service transaction is completed. The MS may choose to indicate the diverted 
address to the caller and return to the idle state, or automatically make a new service request with the 
diverted address as the destination. 

3) The TSCC may send C_ACKD(Mirrored_Reason=Callback) to inform the calling MS that the caller has 
indicated they will call back. 
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b) The TSCC may send progress PDUs to the calHng MS as a vaUd response to the random access request as 
follows: 

1) C_WACKD - An intermediate acknowledgement, more signalling to follow. 

2) C_QACKD - The TSCC has queued the call because the resource requested or called party is busy, more 
signalling to follow. 

3) C_AHOY - The TSCC has sent a C_AHOY PDU with the calling MS address in either the Source or 
Target address information element. 

6.6.1 .4 Called Party Answering Mechanism 

The TSCC may process individual voice and packet data calls using either OACSU or FOACSU. 

A call using OACSU allocates a payload channel as soon as the resource is available to connect that channel. Channel 
Grant PDUs are sent to the calling and called party. When the called party has successfully received the Channel Grant 
the user may be alerted to the incoming call. 

A call using FOACSU checks that the called party is available but the Channel Grant PDUs are not sent by the TSCC 
until the called party indicates RFC (perhaps by an off hook mechanism). Figure 6.39 illustrates the process. 
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Figure 6.39: Call Answer Mechanism for FOACSU 

MS(A) makes a Service Request at point "A". In this example, the TSCC sends an AHOY PDU (point "B") addressed 
to MS(B) that requires an acknowledgement response. The AHOY sets the Service_Kind_Flag=l2 to indicate that the 
call set up is by FOACSU. MS(B) responds with an acknowledgement at point "C". At this point MS(B) alerts the user 
of the incoming call. When the called party is RFC then: 

a) the called party user actively answers the call at point "D" causing MS(B) to send an Answered Random 
Access Request to the TSCC. The Alert state is cancelled; 

b) if a traffic channel resource is available, the TSCC sends a Channel Grant PDUs addressed to MS (A) and 
MS(B), (otherwise the TSCC may queue the call until a traffic channel becomes available). 



6.6.1.4.1 



TSCC response to the Call Answer Random Access 



When a Call Answer random access service PDU is received on the TSCC, the TSCC shall send a response in 
accordance with the random access procedures prescribed in clause 6.2. 

The PDUs that represent a valid response to the voice call single-part service random access request are: 

a) If the MS indicates that the call is accepted (ACCEPT = O2): 

1) an acknowledgement C_WACKD, call is queued, more signalling to follow; 

2) an acknowledgement C_NACKD, system failure, message rejected; 

3) Channel Grant PDU(s) for this call. 
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c) If the MS indicates that the call is rejected (ACCEPT =12): 

1) an acknowledgement C_NACKD, system failure, message rejected; 

2) an acknowledgement C_ACKD, message accepted. 



6.6.1.4.2 



Call Party Answer behaviour for the MS 



A MS indicates that it is RFC by sending a C_RAND random access request complying with the random access 
procedures in clause 6.2. The information elements in the random access request are passed to the CC layer - set 
appropriately as prescribed in table 6.28. The ACCEPT information element indicates if the called party wishes to 
accept (O2) or reject (I2) the call. 

Table 6.28: C RAND information elements for the Answer Call Service 



Information 
Element (I.E) 


I.E 
Length 


length 


Alias 


Value 


Remark 


Service_Options 


7 




EMERG 


O2 








O2 


Privacy (see note 1 ) 




SUPED_SV 


O2 






BCAST_SV 


O2 






OVCM_SV 


O2 




2 


PRIORTY_SV 


OO2 




Proxy Flag 


1 




PROXY 


O2 




Appended_Supplem 
entary Data 


2 




SUPED_VAL 


OO2 




Accept/Reject 


1 




ACCEPT 


O2 


The user has accepted this FOACSU call 


I2 


The user does not wish to accept this call 


Reserved 


1 






O2 




Service_Kind 


4 




CALL_ANS 


IOOI2 


Call Answer Service 


Target_address or 
Gateway 


24 






Value 


Target Address (see note 2) 


Source address 


24 






Value 


Individual Address of the requesting MS 


NOTE 1 : Privacy is not defined in the present document. 
NOTE 2: Target_Address represents an Individual address. 



6.6.1.5 



Maintenance of call progress waiting tinners 



6.6.1.5.1 



Call waiting timer for the calling MS 



From the point at which a MS has requested a particular service, the TSCC may send acknowledgement PDUs to 
indicate to the calling MS the progress of the service request. If the calling MS receives an acknowledgement to its 
random access request, it shall start one of two timers. The timer TP_Timer shall be started for a voice or packet data 
random access service request that requires the allocation of a payload channel. The timer TNP_Timer shall be started 
for a call that only uses the TSCC for the call. If, while the timer is running the MS receives another acknowledgement 
PDU, the timer shall be refreshed. If the timer expires, the MS may assume that the TSCC has abandoned the call and 
the MS shall return to the idle state. 

The TSCC shall maintain an identical timer. If the TSCC receives a random access request for a call that requires the 
allocation of a payload channel, it will start timer TP_Timer. A call that only requires the TSCC shall start timer 
TNP_Timer. The TSCC may send a further acknowledgement to the calling MS and refresh its timer. If the timer 
expires, the TSCC shall abandon that call service. 
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6.6.1 .5.2 Call waiting timer for the called MS 

If a MS receives an individually addressed C_AHOY PDU (Service_Kind=00002) or C_AHOY PDU 
(Service_Kind=00102) indicating an availability check for a payload channel, the MS shall start timer T_Pending. 

While T_Pending is running, if the MS receives a Talkgroup voice channel grant or Packet Data Talkgroup Channel 
Grant PDU, the PDU shall be discarded. If the timer T_Pending expires and the MS has not been directed to a payload 
channel, the MS may assume that the TSCC has abandoned the call that was indicated in the C_AHOY PDU. If the call 
set up is FOACSU, the MS shall be alerting. Expiry of T_Pending shall cancel the MS alerting state. 

If while T_Pending is running, the TSCC transmits another individually addressed C_AHOY PDU 
(Service_Kind=00002) or C_AHOY PDU (Service_Kind=00102), the MS shall refresh timer T_Pending. 

If while T_Pending is running, the TSCC transmits an individually addressed C_AHOY call cancellation PDU 
C_AHOY (Service_Kind=llll2), the T_Pending timer shall be suspended. The MS shall assume that the TSCC has 
abandoned the call. 

The TSCC shall maintain the same timer T_Pending. If the TSCC transmits a C_AHOY PDU (Service_Kind=00002) or 
C_AHOY PDU (Service_Kind=00102) indicating an availability check for a payload channel, T_Pending is started. If 
the TSCC has not transmitted the Channel Grant PDU(s) for this call before T_Pending expires, the TSCC shall 
abandon the call. 

6.6.1 .6 Payload Channel Assignment 

The TSCC shall assign a payload channel for the call by transmitting applicable Channel Grant PDUs for the service 
supported (individual MS or talkgroup). 

The Channel Grant PDUs may be single block CSBK format if the logical channel to absolute Tx / Rx frequency 
relationship is known, or the MBC Channel Grant PDUs may have an appended MBC block that contains the absolute 
Tx /Rx frequencies. 

For individual voice and packet data services to and from certain gateways, the payload channel may select offset 
timing to provide a full duplex service to MS. The TSCC provides a differing gateway identifier to distinguish between 
the aligned and offset mode of payload assignment: 

a) for ahgned timing PSTNI, PABXI, LINEI, IPI (see clause A.4); 

b) for offset timing PSTNDI, PABXDI, LINEDI, IPDI (see clause A.4). 

Channel Grant PDUs may be transmitted by the TS on a payload channel to swap the call to a replacement channel. 

If a particular talkgroup call is active on a payload channel, the TSCC may continue to transmit appropriately addressed 
Channel Grant PDUs at regular intervals to permit late joining MSs (MSs who may have just arrived on the control 
channel) to join that talkgroup call. 
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6.6.2 Voice Call Procedures 

Voice calls require a payload channel over which the call is conducted. Calls may be transacted between the entities in 
table 6.29. 

Table 6.29: Voice Call Services 



Mode 


Originator 


Recipient 




MS 


MS or Talkgroup 


MS 


All MS (Broadcast) 


MS 


Line Connected destination through a Gateway: 
PABX Extension 
PSTN destination 
Other gateway equipped for voice 


Line Connected source via a Gateway: 
PABX Extension 
PSTN destination 
Other gateways equipped for voice 


MS or Talkgroup or All MS 



The Individual/Talkgroup PDU in the Random Access Service Request shall determine if the caller has selected a Tier 
III service to an individual MS or a talkgroup. 

The Service_Options PDU in the Random Access Service Request shall activate options for the Voice Call Service 
Request: 

• Emergency service: 

Emergency calls shall take precedence over all other calls. Emergency call may be pre-emptive causing 
another call to be cleared down if the resource requested for the emergency call is not available. 

• Supplementary_user data Transfer Service requested for this call: 

Information may be sent to the called party as part of and to support another call service. For instance the 
PSTN Call Line Identity may be passed to the called party as part of a voice call setup. 

• Broadcast service: 

The Broadcast Call Voice service provides a one-way voice call from any user to a predetermined 
talkgroup. 

• OVCM call: 

The Open Voice Channel Mode service allows users to monitor and participate to the voice channel 
activity. From the voice activity originator's point of view the OVCM gives the opportunity to place 
group and individual calls that may be listened from third party users that are not the targeted users of the 
call. In addition these third party users are part of the conversation in progress and they can also talk. 

Third party users are those that have radios configured to take part to calls set as OVCM and not 
addressed explicitly to them. 



Priority: 



6.6.2.1 



The priority option permits the originator to select one of four levels of priority. The TSCC may manage 
and manipulate a call queue to cause calls with a higher priority to mature faster. The procedures the 
TSCC may employ are not prescribed in the present document. 

Voice Call Procedures for the TSCC 



A MS requests a Tier III voice service by generating a random access request PDU with the Target Address set to one 
of the following: 

a) an individual MS address (single-part call set-up); 

b) a talkgroup MS address (single-part call set-up); 
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c) a gateway address that indicates a multi-part call set-up. The gateway address indicates the destination 
e.g. PABXI for a call to a PABX, PSTNI for a call to the PSTN, LINEI for a call to a line connected 
destination, DISPATI for a call to the system dispatcher. For flexibility calls to line connected destinations and 
the system dispatcher, such calls are treated in the same way as PABX/PSTN calls. 

When the TSCC responds to the random access request, it shall start a timer (TP_Timer). This timer shall be refreshed 
if the TSCC sends further call related PDUs C_WACKD, C_QACKD or C_AHOY, to the calling party. 

6.6.2.1 .1 TSCC Response to single-part voice call set-up 

When a random access voice service PDU is received on the TSCC, the TSCC shall send a response in accordance with 
the random access procedures prescribed in clause 6.2. 

The PDUs that represent a valid response to the voice call single-part service random access request are: 

a) An acknowledgement PDU C_NACKD, C_QACKD, C_WACKD, C_ACKD(mirrored_reason=callback). 

b) A UDT Head + appended block(s) (voice call is diverted) UDT Header PDUs Source_Address=DIVERTI 
(conveying a diverted address) Supplementary Flag = I2 and UDT_Response = O2. 

c) A C_AHOY PDU from the calling party MSID (called party radio check) if the call is to an individual MS 
address. (C_AHOY Source address=calling party MS ID, Destination address=called party MS ID) (see 
clause 6.6.2.1.4). 

d) A C_AHOY PDU from AUTHI (MS authentication check) (see 6.4.8.2). 

e) A C_AHOY PDU from SUPLI for the calling MS to send supplementary_user data (see clause 6.4.13). 

f) A Channel Grant PDU(s) for this call. 

For e) the TSCC shall then invoke the UDT procedure by sending the C_AHOY to the calling MS to send the 
supplementary_user data. The format of the supplementary_user data is specified in the UDT. If the TSCC does not 
successfully receive the UDT from the MS, the TSCC may repeat the C_AHOY, or transmit a C_NACKD to indicate 
failure of the call, or continue with the call setup and abandon the supplementary_user data. 

NOTE: A TSCC may send a C_AHOY addressed to a talkgroup to check that at least one member of the 
talkgroup is listening to the TSCC. 

The purpose of the C_AHOY PDU in c), d) and e) is identified by the source address information element 
in the C_AHOY PDU. For a called party check it is the called party MD ID or talkgroup. For an 
authentication check it is the gateway address AUTHI. For e) it is SUPLI. c), d) and e) may be sent in any 
order. 

6.6.2.1 .2 TSCC Response to multi-part voice call set-up 

For calls to extended_addresses, the MS requests multi-part addressing by generating a voice call random access request 
with the Destination Address information element set to a gateway address (PABXI, PSTNI, etc.) and the Proxy Flag 
information element to indicate if one or two appended UDT blocks are required to transport the extended_address from 
the MS. For calls to the PABX/PSTN/LINE/dispatcher one appended UDT can carry up to 20 dialled digits, and in that 
case the Proxy Flag information element shall be set to O2, and for the number of dialled digits = 21 to 44 the Proxy 
Flag information element shall be set to I2. 

The PDUs that shall represent a valid response to the voice call multi-part part voice service random access request are: 

a) An acknowledgement PDU C_NACKD, C_WACKD(mirrored_reason=Wait), C_QACKD. 

b) A C_AHOY PDU from PABXI, PSTNI, LINEI, DISPATI for the calHng MS to send the extended_address 
information. 

c) A C_AHOY PDU from SUPLI for the calling MS to send supplementary_user data (see clause 6.4.13). 
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For b) the TSCC shall then invoke the UDT procedure by sending a C_AHOY to the calling MS to send the 
extended_address information. For a call to the PABX, PSTN, LINEI or DISPATI the extended_address information 
shall be BCD digits. The Proxy Flag information element in the C-AHOY PDU shall be copied from the Proxy Flag 
information element received from the MS C_RAND PDU. If the TSCC does not successfully receive the UDT from 
the MS, the TSCC may repeat the C_AHOY, or transmit a C_NACKD to indicate failure of the call. 

For c) the TSCC shall then invoke the UDT procedure by sending the C_AHOY to the calling MS to send the 
supplementary_user data. The format of the supplementary_user data is specified in the UDT. If the TSCC does not 
successfully receive the UDT from the MS, the TSCC may repeat the C_AHOY, or transmit a C_NACKD to indicate 
failure of the call, or continue with the call setup and abandon the supplementary_user data. 

6.6.2.1 .3 Acknowledgements sent by the TSCC to the calling MS (voice) 

The TSCC may send acknowledgement PDUs following the random access voice service request to indicate the 
progress of the call, to terminate the call or indicate call-back. If the TSCC sends a PDU to indicate the progress of a 
call it shall start a waiting timer TP_Timer. (The calling party MS maintains a similar timer): 

a) Progress PDUs are: 

1) C_WACKD: Intermediate acknowledgement. More PDUs to follow; 

2) C_QACKD: Called MS engaged in another call; 

3) C_QACKD: Call is queued because the resource is in use at the moment. 

b) Termination PDUs are selected from an appropriate Reason information element in a C_NACKD PDU (see 
clause 7.2.8): 

1) C_NACKD. 

c) Call-Back PDUs indicate to the calling MS that the voice call service has been accepted by the called party for 
call back: 

1) C_ACKD(mirrored_reason=CallBack). 

d) If the TS has previously accepted a call diversion indicating that this type of service request should be directed 
to another called party, the TSCC shall invoke the UDT and send a UDT Head + Appended data to the calling 
party. UDT Header PDUs Source Address=DIVERTI (conveying a diverted address) Supplementary Flag = I2 
and UDT_Response = O2. 

6.6.2.1 .4 Voice Radio Check 

For calls to individual MS, the TSCC shall check that the called party is in radio contact and will accept the call before 
a payload channel is allocated. 

The TSCC may check availability of the called party by: 

a) Sending a C_AHOY PDU to that called party. If the message C_AHOY Service_Kind=00002 
Service_Kind_Flag=02 then the TSCC is checking that the MS is in radio contact and can accept this call 
immediately. If the message C_AHOY Service_Kind=00002 Service_Kind_Flag=l2 then the TSCC is 
checking that MS is RFC. 

b) Sending a Multi-block UDT with supplementary_user data (if the supplementary_user data service is active for 
this call). 

If a response is not received from the called party the TSCC may repeat the C_AHOY. 

The availability check demands a response from the called party: 

• If the response is C_NACKU, the TSCC shall send an appropriate call failed response to the calling MS and 
echo the Reason in the C_NACKU PDU (mirrored_reason). 

• If the response is C_ACKU(Reason=CallBack), the TSCC shall send an appropriate CallBack response to the 
calling MS, C_ACKD (mirrored_reason= 0100 OIOI2). 
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• If the response is C_ACKU(Reason=Message_ Accepted), the TSCC shall progress the service request and 
allocate a payload channel by transmitting appropriate Channel Grant PDUs. 

• If the called MS is FOACSU enabled, a vaHd response to C_AHOY Service_Kind=00002 
Service_Kind_Flag=l2 is C_ACKU(Reason= MS_ Alerting), i.e. MS alerting but not yet RFC. 

NOTE: A multi-block UDT cannot transfer all Service Options to the called party. If the Service Options are 

essential to the operation of the system, a C_AHOY/response and a Multi_block UDT/response may be 
sent to the MS. The two messages may be sent in any order. 

6.6.2.1 .5 Availability Check for Voice Calls connected through Gateways 

For calls connected through gateways the TS equipment may wait until the destination is RFC before allocating the 
payload channel. For example a TS may wait until the PSTN handset has been answered before sending Channel Grant 
PDUs. 

6.6.2.2 Voice Gall Procedures for MS 

A MS is able to request a voice call service to another individual MS or a talkgroup using a single-part service request. 
For a voice service requested to extended_addresses through a gateway the MS requests a multi-part service request. 
For multi-part service requests the MS sets the gateway address as the called party. The full destination address is then 
uploaded from the MS to the TSCC by the UDT procedure. 

A MS requests a voice service by sending a C_RAND random access request complying with the random access 
procedures in clause 6.2. The information elements in the random access request are passed to the CC layer - set 
appropriately as prescribed in table 6.30. 
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Table 6.30: C RAND information elements for a Voice Call Service 



Information 
Element (I.E) 


I.E 
Length 


length 


Alias 


Value 


Remark 


Service_Options 


7 




EMERG 


O2 


Non-emergency service 


I2 


Emergency service 






O2 


Privacy (see note 1 ) 




SUPED_SV 


O2 


No Supplementary_user data Transfer 
Service required for this call 


I2 


Supplementary_user data Transfer Service 
requested for this call 




BCAST_SV 


O2 


Non-broadcast service 


I2 


Broadcast service (see note 2) 




OVCM_SV 


O2 


Non-OVCM call 


I2 


OVCM call 


2 


PRIORTY_SV 
(see note 3) 


OO2 


Normal (low) priority 


OI2 


Medium Priority 


IO2 


High Priority 


II2 


Highest Priority 


Proxy Flag 


1 




PROXY 


O2 


Number of Extended BCD digits for 
addressing through a gateway = 1 to 20 


I2 


Number of Extended BCD digits for 
addressing through a gateway = 21 to 44 


Appended_Supplem 
entary Data 


2 




SUPED_VAL 


Value 


Number of appended UDTs required to 
transport supplementary user data 


Ambient Listening 
Service 


1 




ALS_SERV 


O2 


Ambient Listening Service not requested 


I2 


Ambient Listening Service requested 


Reserved 


1 






O2 




Service_Kind 


4 




IND_V_SRV 


OOOO2 


Individual Voice Call Service 


GRP_V_SRV 


0001 2 


Talkgroup Voice Call Service 


Target_address or 
Gateway 


24 






Value 


Target Address (see note 4) 


Source address 


24 






Value 


Individual Address of the requesting MS 


NOTE 1 : Privacy is not defined in the present document. 

NOTE 2: The broadcast option is only applicable to the talkgoup call service. 

NOTE 3: If EMERG = 1 ^ then PRIORTY_SV is set to OO2. 

NOTE 4: If Service_Kind = IND_V_SRV then Target_Address represents an Individual address. 

If Service_Kind = GRP_V_SRV then Target_Address represents a Talkgroup. 
NOTE 5: OVCM calls apply to MS destinations only. 



6.6.2.2.1 



Initiating a single-part voice call service 



For a voice service request to an individual MS or talkgroup, the destination address is completely expressed by the 
Target Address information element in the random access PDU. The Service_Kind specifies if the voice call service is 
addressed to an individual address or a talkgroup. 

6.6.2.2.2 Response to the single-part voice service request 

MS shall accept the following PDUs as valid response to the single-part voice service request. 

a) an acknowledgement C_WACKD, C_QACKD, C_NACKD, C_NACKD(mirrored_reason), 
C_ACKD(mirrored_reason=callback); 

b) a C_AHOY called party radio check; 
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c) a UDT header + appended UDT block. UDT Header Source_Address=DIVERTI (conveying a diverted 
address) Supplementary Flag = I2 and UDT_Response = O2; 

d) a Channel Grant PDU; 

e) if the Service_Options SUPED_SV = I2 a C_AHOY from SUPLI to upload the supplementary_user data from 
the calHng MS. 

6.6.2.2.3 Response to the multi-part voice service request 

MS shall accept the following PDUs as valid response to the multi-part voice service request. 

a) an acknowledgement C_WACKD, C_QACKD, C_NACKD; 

b) a C_AHOY PDU from PABXI,PSTNI,LINEI, DISPATI to upload the extended_address: 

1) for a call to the PABX/PSTN/LINEI/DISPATI a C_AHOY to upload the dialled digits; 

2) if the Service_Options SUPED_SV = I2 a C_AHOY from SUPLI to upload the supplementary data from 
the calHng MS. 

For b), if the Voice Call Service Request requires extended_address information and the calling MS has selected the 
Supplementary Data in the Service_Options, the TSCC uploads the information in two steps. The order in which the 
information is uploaded is not prescribed because the C_AHOY specifically indicates which UDT inbound procedure 
has been invoked by setting appropriate unambiguous Gateway information elements in the C_AHOY PDU. The 
gateway information elements for C_AHOY PDUs to support voice services are prescribed in table 6.31. 

Table 6.31 : C_AHOY information elements for multi-part voice call setup 



Action 


Gateway 
address 


Remark 


MS send PSTN digits 


PSTNI 


The calling party shall send BCD dialled digits 


IVIS sends PABX digits 


PABXI 


The calling party shall send BCD dialled digits 


IVIS sends digits to the line 


LINE! 


The calling party shall send BCD dialled digits 


IVIS sends digits to dial the dispatcher 


DISPATI 


The calling party shall send BCD dialled digits 


MS sends supplementary user data 


SUPLI 


The format of the data shall be determined by the calling party 



6.6.2.2.4 



Acknowledgements received by the calling MS (voice) 



At some time after sending the voice service request random access PDU the calling MS may receive an 
acknowledgement. On receiving the acknowledgement, the MS shall start or restart a waiting timer, TP_Timer. (The 
TSCC maintains a similar timer.) 

The MS shall take the actions prescribed: 

a) Progress PDUs for a single-part voice call Service Request are: 

1) C_WACKD: Intermediate acknowledgement. More PDUs to follow. The MS shall wait TP_Timer for 
further signalling and may indicate a possible delay to the calling MS; 

2) C_QACKD: Called MS engaged in another call. The MS shall wait TP_Timer for further signalling; 

3) C_QACKD: Call is queued because the resource is in use at the moment. The MS shall wait TP_Timer 
for further signalling and may indicate a possible delay to the calling MS. 

(The MS may choose to differentiate between 1), 2) and 3) by providing the calling MS with a visual or 
audible indication for each of the conditions.) 
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b) Termination PDUs are selected from an appropriate Reason information element in a C_NACKD PDU 
(see clause 7.2.8). If the call was rejected by the calling party, the termination PDU sent by the TS shall be a 
C_NACKD(mirrored_reason) : 

1) C_NACKD: Call refused and terminated. The C_NACKD PDU provides a versatile range of Reason 
codes and mirrored reason codes to indicate to the calling party why the Service request was terminated. 
The calling party shall return to the idle state. 

c) Call-Back PDU to indicate to the calling MS that the voice call service has been accepted by the called party 
for call back. Service concluded. The calling party shall return to the idle state: 

1) C_ACKD(mirrored_reason=CallBack). 

d) If the TS has previously accepted a call diversion indicating that this type of service request be directed to 
another called party, a UDT Head + Appended data indicating the diverted address. 

6.6.2.2.5 Availability Check to the called party (voice) 

For an individual MS address call set-up, the called MS shall receive a radio check to which it shall respond with an 
appropriate acknowledgement: 

• The called party shall respond C_NACKU, if it cannot accept the call (the TSCC shall send an appropriate call 
failed response to the calling MS). 

• The called party shall respond C_ACKU(Reason=CallBack), if the called MS wishes to return the call at some 
future time (the TSCC shall send an appropriate CallBack response (mirrored reason) to the calling MS). 

• The called party shall respond C_ACKU(Reason=Message_Accepted), if the call is accepted and the MS can 
accept the call immediately (the TSCC shall progress the service request and allocate a payload channel by 
transmitting appropriate Channel Grant PDUs). 

• If the MS is FOACSU enabled and the message to which the MS is sending the acknowledgment is C_AHOY 
Service_Kind=00002 Service_Kind_Flag=l2 then a valid response is C_ACKU(Reason= MS_Alerting), 

i.e MS alerting but not yet RFC. After sending the acknowledgment the MS may indicate RFC by sending a 
C_RAND (Answer Call Service). If the called MS is alerting but the user does not wish to accept the call the 
MS shall send a C_RAND(Cancel Call Service) 

6.6.2.2.6 Payload Channel Allocation 

MS shall check the address information elements received in Voice Channel Grant PDUs. If it is determined that the 
Channel Grant PDU is applicable then it shall retune to the indicated physical/logical payload channel to commence the 
Voice Service: 

a) For Private Voice Channel Grant CSBK PDU: 

1) If an MS receives a Private Channel Grant PDU where either the Source Address or the Target Address 
information element matches its individual address then that PDU is applicable. 

b) Talkgroup Voice Channel Grant CSBK PDU (OVCM information element = O2): 

1) If an MS receives a Talkgroup Channel Grant PDU with the Target Address information element 
matching one of its talkgroup addresses then that PDU is applicable. 



2) If an MS receives a Talkgroup Channel Grant PDU with the Source Address matching its individual 
address then that PDU is applicable. 

3) If an MS receives a Broadcast Talkgroup Channel Grant PDU with the Target Address matching one of 
its talkgroup addresses then that PDU is applicable. 

4) If an MS receives a Broadcast Talkgroup Channel Grant PDU with the Source Address matching its 
individual address then that PDU is applicable. 
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c) Talkgroup Voice Channel Grant CSBK PDU (OVCM information element = I2): 

1) If an MS receives a Talkgroup Channel Grant PDU with the Target Address information element 
matching one of its talkgroup addresses or one of its OVCM addresses then that PDU is applicable. 



2) If an MS receives a Talkgroup Channel Grant PDU with the Source Address matching its individual 
address then that PDU is applicable. 

3) If an MS receives a Broadcast Talkgroup Channel Grant PDU with the Target Address matching one of 
its talkgroup addresses or one of its OVCM addresses then that PDU is applicable. 

4) If an MS receives a Broadcast Talkgroup Channel Grant PDU with the Source Address matching its 
individual address then that PDU is applicable. 

6.6.2.2.7 Calling MS in single part voice call setup SDL 

Figures 6.40 and 6.41 SDL is defined from the behaviour description in clause 6.6.2.2. 

NOTE: The state names are not related to state names in TS 102 361-1 [5] and TS 102 361-2 [6]. 



process VoiceCallSetup 



Rx_C_NACKD, C_ACKD 

Rx C ACKD (reason = 

' ^ ^CallBack) 



idle 



PTT_req 



Tx_C_RAND> 



TP_Timer 



WaitTsRsp 



WaitTsRsp 



^IZ^S. Bx.PV.GR^ANT 



1(2) 



/* Calling MS single part call 
setup for indivdual call. 7 



Rx_C_UDWD n Call redirect TP_Timer < 



reset 
(TP_Timer) 



idle 



set 
(TP_Timer) 



reset 
(TP_Timer) 



\ 'Change to 
aitTsProgresk payload 
J cha n nel' 



reset 
(TP_Timer) 



WaitUdtAp 



idle 



InCall 



Figure 6.40 (sheet 1 of 2): Single part OACSU voice call setup SDL 
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Figure 6.41 (sheet 2 of 2): Single part OACSU voice call setup SDL 
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6.6.2.2.8 Call set-up MSC that also transfers supplementary_user data. 

Figure 6.42 illustrates a call set-up from an MSC where supplementary_user data is transferred as part of the call set-up. 
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6.6.2.3 



Figure 6.42: MS OACSU Call set-up with Supplementary data 



Timing requirements for the allocation of a Payload Channel 



MSs are directed to a payload physical/logical channel for voice and certain data services. Where a payload channel is 
allocated MS shall comply with the timing requirement defined in this clause. 
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6.6.2.3.1 TSCC and Payload channel are time aligned 

If slot 1 on the payload channel is selected by the TS, then the MS shall be capable of receiving or transmitting 
information in the second occurrence of slot 1 on the payload channel after having decoded the Channel grant on the 
TSCC successfully. 

If slot 2 on the payload channel is selected by the TS, then the MS shall be capable of receiving or transmitting 
information in the third occurrence of slot 2 on the payload channel after having successfully decoded the Channel 
Grant on the TSCC. 

Independent of the payload assignment to slot 1 or 2 on the payload channel, the payload channel shall start to transmit 
IDLE slots outbound, following the transmission of the first channel grant on the TSCC until payload for transmission 
is available. 

6.6.2.3.2 TSCC and Payload channel are not time aligned 

The MS shall be capable of receiving or transmitting on the next upcoming assigned payload slot after it successfully 
synchronised to the outbound payload channel. 

The MS shall be capable of receiving or transmitting on the next upcoming assigned payload slot after it successfully 
synchronised to the outbound payload channel. 

The Synchronisation period shall include the occurrence of 4 C ACH on the traffic channel after the first sync 
opportunity for the MS. This is to allow for robust TC bit decoding in fringe situations. 

Independent of the payload assignment to slot 1 or 2 on the payload channel, the payload channel shall start to transmit 
IDLE slots on the outbound following the transmission of the first channel grant on the TSCC. These IDLE slots shall 
be transmitted until a minimum of 4 CACH, after the first MS Sync pattern receive opportunity, have been 
transmitted .Note: Depending on the actual RF coverage for the intended area to be served by the system a number of 
4 CACH might be regarded as not necessary. 

It is recommended to have a programmable parameter in the infrastructure and MS with a value of 2 or 4. 

6.6.2.4 Procedures for the Voice Payload Channel 

MSs are directed to a voice payload physical/logical channel on the TSCC. When the voice call is terminated, MS 
returns to the TSCC and the payload channel is reassigned to another call. 

A voice call may extend over several MS PTT items for the duration of the call (unless the call is terminated 
prematurely by the expiry of the voice payload timer) if the system has assigned the call as "message trunking". If the 
system has assigned the call as pure "transmission trunking" the call shall be terminated after the end of each PTT item. 
A third possibility is that the call has been assigned as "quasi-transmission trunking". In this case a short interval timer 
(TV_Hangtime) between PTT items holds the payload channel. If this short interval timer expires, the call is terminated 
and the next PTT item sets up a new call. 

The voice payload channel may be assigned to one of two basic timing models. The particular timing model is specified 
on the TSCC and signalled to MS by the Channel Grant PDUs (see TS 102 361-1 [5]): 

a) Aligned timing supports Reverse Channel (RC) signalling by providing the receiving MS with a Reverse 
Channel transmit opportunity on the inbound channel without missing any of its outbound traffic. Aligned 
timing also supports "MS to MS" duplex traffic by allowing a MS to transmit in one timeslot and receive the 
repeated transmission of the other MS on the alternative timeslot: 

1) l:l-mode. 1 traffic channel mode: l:l-mode supports one "MS to fixed end" duplex call or one simplex 
call with an optional inbound Reverse Channel using a two frequency BS. 

2) 2:1 -mode. 2 traffic channel mode: 2:1 -mode supports two independent calls which may be either "MS to 
fixed end" duplex calls or simplex calls using a two frequency BS. 

b) Offset timing supports "MS to fixed end" duplex traffic by allowing a MS to transmit in one time slot and 
receive the fixed end transmission on the alternate time slot. 
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The procedures for TS/MS behaviour on the voice payload channel are described in TS 102 361-2 [6]. In the trunked 
environment however, call maintenance PDUs are exchanged between MS and TS in addition to the PDUs described in 
TS 102 361-2 [6]. 

When active, a payload channel shall transmit the CACH in the same form as described in TS 102 361-2 [6], 
clause 7.1.3.2). 

The beginning of a call shall use PATCS method (see TS 102 361-2 [6], clause 5.2.2.1). For an individual MS call 
service, the called party will already have had a radio check as part of the call set-up procedure. 



6.6.2.4.1 



TS Procedures for the Voice Payload Channel 



A physical payload channel may carry one or two independent voice calls. If a new physical channel is allocated on the 
TSCC, the CCL_BS shall start both the CCL_1 and CCL_2 processes as described in TS 102 361-2 [6], 
clause 5.1.1.1.3). and start the voice channel payload timer as follows: 

a) For an individual MS/MS or MS/Talkgroup normal or high priority call T_MS-MS_TIMER. 

b) For a gateway individual MS or Talkgroup normal or high priority call T_MS-Line_TIMER. 

c) For an emergency call T_EMERG_TIMER. 



6.6.2.4.1.1 



MS radio check 



The TS may poll an individual MS to check if the MS is active on the payload channel by transmitting a P_AHOY PDU 
with the information elements set as follows. 

The TSCC transmits a P_AHOY with the information elements as illustrated in table 6.32. 

Table 6.32: P AHOY information elements for voice service individual radio check 



Service_Options_Mirror 


7 


000 OOOO2 


Service_Kind_Flag 


1 


O2 


Ambient Listening Service 


1 


O2 - The calling party has not requested ALS 


I2 - The calling party has requested ALS (See 
Note) 


IG 


1 


O2 - The Target address is an MS individual ID 


Appended_Blocks 


2 


OO2 


Service_Kind 


4 


Individual Call Service - OOOO2 


Target address 


24 


Individual Address of Called MS 


Source Address or Gateway 


24 


TSI 



The response is P_ACKU(Reason=Message_ Accepted). 

The TS may also poll a talkgroup to check if at least one member of the talkgroup is active on the payload channel by 
transmitting a P_AHOY PDU with the information elements as illustrated in table 6.33. 

Table 6.33: P_AHOY information elements for voice service talkgroup radio check 



Service_Options_Mirror 


7 


000 OOOO2 


Service_Kind_Flag 


1 


O2 


Ambient Listening Service 


1 


O2 - Not Applicable 


IG 


1 


I2 - The Target address is a talkgroup 


Appended_Blocks 


2 


OO2 


Service_Kind 


4 


Talkgroup Call Service - 0001 2 


Target address 


24 


Address of the talkgroup 


Source Address or Gateway 


24 


TSI 
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The response is P_ACKU (Reason=Message_ Accepted). If more than one MS makes a response to this PDU, it is Hkely 
that the TS will be unable to decode it because of collisions. The purpose of this procedure is to determine if any 
talkgroups are active, therefore the TS may use the presence of the burst for the result of the talkgroup radio check. 

NOTE: The TS may poll an individual MS or a talkgroup to check if the MS is active on the payload channel 
irrespective of the Call Service. This procedure is described in clause 6.4.12. 

6.6.2.4.1 .2 Authentication Check 

The authentication procedures are identical to the authentication procedures described in clause 6.4.8.2 but with the 
C_AHOY PDU replaced by a P_AHOY PDU. 

6.6.2.4.1 .3 Disabling/enabling a users PIT 

The TS may at any time send a P_PROTECT (Protect_Kind=DIS_PTT) addressed to an individual MS, talkgroup, or 
AlLUnit ID15 (see TS 102 361-1 [5], annex A) to disable the PTT. Since the P_PROTECT PDU is unacknowledged 
the PDU may be repeated at layer 2. 

The TS may also at any time send a P_PROTECT (Protect_Kind=EN_PTT) addressed to an individual MS, talkgroup, 
or AlLUnit ID15 (see TS 102 361-1 [5], annex A) to enable the PTT. Since the P_PROTECT PDU is unacknowledged 
the PDU may be repeated at layer 2. 

6.6.2.4.1 .4 Swapping the call to a replacement voice payload channel 

The TS may send Channel Grant PDUs on the payload channel to move MS already active to an alternative voice 
payload channel. If MS had previously received a P_PROTECT to disable their PTT, the PTT shall be re-enabled on the 
replacement voice payload channel unless the call service was a broadcast when called party(s) shall retain their PTT 
status (enable/disable) from the original call. 

6.6.2.4.1 .5 Removing MS from the payload channel that are not legitimate parties 

The TS may transmit P_PROTECT(ILLEGALLY_PARKED) PDUs at any time. A MS whose address does not match 
either of the address information elements in the P_PROTECT PDU shall leave the payload channel without making 
any further transmissions. 

6.6.2.4.1 .6 Clearing down the voice call 

The TS shall clear the parties involved in the payload voice call if: 

a) The relevant overall payload call timer T_MS-MS_TIMER, T_MS-Line_TIMER or T_EMERG_TIMER 
expires. 

b) The TS receives a P_MAINT (Maint_Kind = DISCON) PDU. 

c) The TS detects by any other means that the call has ended (e.g. PSTN destination on hook). 

d) The TV_Hangtime interval timer expires. 

The TS shall clear down the call by transmitting P_CLEAR PDU(s). Since this PDU is not acknowledged it may be 
repeated at layer 2. 

6.6.2.4.1 .7 TS single part voice call termination MSC 

Figure 6.43 illustrates the MSC showing the TS voice call termination procedure for MS to MS or MS-Talkgroup call 
on payload channel as described in clause 6.6.2.3.1.6. 

NOTE: The option TS detects by other means that the call has ended' is not illustrated in this MSC. 
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MSC TS MsMsVoiceCallClearDown 



/* TS voice call clear down of a MS to MS or 
MS to Talkgroup call on payload channel. 7 



TS_CCL 



TS_DLL 



TS_PL 



InCall 



alt 



T_MsMs_Timer 



opt 



TV_Hangtime 



Rx P MAINT 



(Maint_Kind=DISCON) 



Tx P CLEAR 



(Cancel Call Service) 



Tx CSBK 



(P_CLEAR) 



Rx_P_ACK 



( Message_Accepted) 



Rx_CSBK 



(P_MAINT) 



Rx_CSBK 



(P_ACK) 



Figure 6.43: Voice Call Termination MSC 
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6.6.2.4.1 .8 Clearing down a particular MS or talkgroup 

The TS may selectively clear an individual MS by transmitting a P_AHOY with information elements set as table 6.34. 

Table 6.34: P_AHOY information elements to clear an individual MS from a voice payload channel 



Service_Options_Mirror 


7 


000 OOOO2 


Service_Kind_Flag 


1 


O2 Indicates tiiat tine target is an Individual Address 


Ambient Listening Service 


1 


O2 - Not Applicable 


IG 


1 


O2 - The Target address is an MS individual ID 


Appended_Blocks 


2 


OO2 


Service_Kind 


4 


Cancel Call Service - 1 1 1 12 Service_Kind_Flag - O2 


Target address 


24 


Individual Address of MS 


Source Address or Gateway 


24 


TSI (see clause A.4) 



The permitted response is P_ACKU(Message_Accepted). 

The TS may clear a talkgroup by transmitting a P_AHOY with information elements set as table 6.35. 

Table 6.35: P_AHOY information elements to clear a talkgroup from a voice payload channel 



Service_Options_Mirror 


7 


000 OOOO2 


Service_Kind_Flag 


1 


I2 Indicates that the target is a talkgroup 


Ambient Listening Service 


1 


O2 - Not Applicable 


IG 


1 


I2 - The Target address is a talkgroup 


Appended_Blocks 


2 


OO2 


Service_Kind 


4 


Cancel Call Service - 1 1 1 12 


Target address 


24 


Talkgroup 


Source Address or Gateway 


24 


TSI 



The permitted response is P_ACKU(Message_Accepted). 



6.6.2.4.2 



6.6.2.4.2.1 



MS Procedures for the Voice Payload Channel 



MS receives an MS radio check 



If an MS receives a P_AHOY to its individual address with information elements set as table 6.32, then it shall respond 
with a P_ACKU (Reason=message_accepted). 

If an MS receives a P_AHOY to the talkgroup address previously transmitted in the Channel Grant PDU that directed 
this MS to the payload channel (PDUs set as table 6.33), then it shall respond with a P_ACKU 
(Reason=message_accepted). 



6.6.2.4.2.2 



MS receives an Authentication Check Challenge 



The authentication procedures are identical to the authentication procedures described in clause 6.4.8.2 but with the 
authentication response C_ACKU PDU replaced by a P_ACKU PDU. 



6.6.2.4.2.3 



Disabling/enabling a users PTT 



If the MS receives a P_PROTECT (Protect_Kind=DIS_PTT) addressed to its individual address, to it is talkgroup 
address previously transmitted in the Channel Grant PDU directed it to the payload channel, or All_Unit ID 15 
(see TS 102 361-1 [5], annex A), the MS shall disable it is PTT. 

If the MS receives a P_PROTECT (Protect_Kind=EN_PTT) addressed to its individual address, to it is talkgroup 
address previously transmitted in the Channel Grant PDU, or All_Unit ID 15 (see TS 102 361-1 [5], annex A), the MS 
shall re-enable it is PTT unless this MS was the recipient of a broadcast call. 
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6.6.2.4.2.4 MS receives a Channel Grant PDU(s) 

If a MS receives an applicable Channel Grant addressed to its individual address or to it is talkgroup address previously 
transmitted in the Channel Grant PDU directed it to the payload channel, then it shall retune to the designated 
physical/logical channel. If the PTT was disabled prior to receiving the Channel Grant, the PTT shall be re-enabled 
unless this MS was the recipient of a broadcast call set-up or a call to All-Unit ID. 

6.6.2.4.2.5 End of call 

The MS shall signify the end of the call by transmitting a number of P_MAINT (Maint_Kind=DISCON). The MS shall 
send the P_MAINT PDUs consecutively then return to the control channel acquisition procedures (it is suggested that 
the TSCC sampled is the TSCC that transferred the call to the payload channel). 

6.6.2.4.2.6 MS receives P_CLEAR 

If a MS receives an applicable P_CLEAR PDU then it shall move to the TSCC indicated by the Logical Physical 
Channel Number PDU. 

6.6.2.4.2.7 MS receives a selective clear P_AHOY 

If a MS receives an individually addressed P_AHOY, Service_Kind=llll2, Service_Kind_Flag=02 information 
element then it shall send a P_ACKU (Reason=Message_Accepted), abandon the payload channel and return to the 
control channel acquisition procedures (it is suggested that the TSCC initially sampled is the TSCC that transferred the 
call to the payload channel). 

If a MS receives a P_AHOY, Service_Kind=l 1 1 12, Service_Kind_Flag=l2 information element addressed to it is 
talkgroup address previously transmitted in the Channel Grant PDU the talkgroup then it shall send a PACKU 
(Reason=Message_Accepted) abandon the payload channel and return to the control channel acquisition procedures (it 
is suggested that the TSCC initially sampled is the TSCC that transferred the call to the payload channel). 

6.6.2.4.2.8 MS receives a P_PROTECT PDU(s) 

If a MS receives a P_PROTECT(ILLEGALLY_PARKED) PDU, and the source or target address in the P_PROTECT 
PDU does not match the source or target address from the Channel Grant PDU that directed the MS to the payload 
channel, the MS shall leave the payload channel without making any further transmissions. 

6.6.2.4.2.9 Time out on the Payload Channel 

A MS shall maintain a number of timers while active on a voice payload channel. 

a) Inactivity timer: 

A MS shall measure the length of time the MS is unable to detect adequate signal quality. If the MS fails 
to detect adequate signal quality for a continuous time TV_Inactive, the MS shall assume that the call has 
ended and return to the control channel acquisition procedures without sending any call termination 
signalling (it is suggested that the TSCC sampled is the TSCC that transferred the call to the payload 
channel). 

b) Item Duration timer: 

A MS shall maintain a maximum item duration timer. If the MS reaches the maximum item duration 
TV_Item, the MS shall transmit a Terminator with LC, disable the PTT and wait until the user releases 
the PTT before re-enabling the PTT. 

c) An overall payload call timer: 

If the overall voice payload call timer T_MS-MS_TIMER, T_MS-Line_TIMER or T_EMERG_TIMER 
expires, the MS shall transmit a number (N_Maint) of P_MAINT PDUs consecutively then return to the 
control channel acquisition procedures (it is suggested that the TSCC sampled is the TSCC that 
transferred the call to the payload channel) If the MS was sending speech frames when the overall voice 
payload call timer expires, the MS shall transmit a Terminator with LC prior to transmitting the 
P MAINTPDUs. 
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6.6.3 Packet Data Call Procedures 

Packet data calls require a payload channel over which the call is conducted. Calls may be transacted between the 
entities in table 6.36. 

Table 6.36: Packet Data Call Services 



Mode 


Originator 


Recipient 


Packet Data 


MS 


MS or Talkgroup 


MS 


All MS (Broadcast) 


MS 


Line Connected destination through a Gateway: 
IP Gateway 
Data Gateway 
Other gateway equipped for data 


Line Connected source via a Gateway: 
IP Gateway 
Data Gateway 
Other gateway equipped for data 


MS or Talkgroup or All MS 



A packet data payload channel may support multiple simultaneous calls. 

6.6.3.1 Packet Data Call Procedures for the TSCC 

A MS requests a Tier III service by generating a random access request PDU with the Target Address set to: 

a) An individual MS address (single-part call setup). 

b) A talkgroup MS address (single-part call setup). 

c) A gateway address that indicates a multi-part call setup. 

When the TSCC responds to the random access request, it shall start a timer (TP_Timer). This timer shall be refreshed 
if the TSCC sends further call progress PDUs to the calling party. 



6.6.3.1.1 



TSCC Response to single-part packet call set-up 



When a random access packet data PDU is received on the TSCC, the TSCC shall send a response in accordance with 
the random access procedures prescribed in clause 6.2. 

The PDUs that represent a valid response to the packet call single-part service random access request are: 

a) An acknowledgement PDU C_NACKD, C_QACKD, C_WACKD. 

b) A UDT Head + appended block(s) (packet data call is diverted) UDT Header PDUs 
Source_Address=DIVERTI (conveying a diverted address) Supplementary Flag = I2 and 
UDT_Response = O2. 

c) A C_AHOY PDU (called party radio check). 

d) A C_AHOY PDU from AUTHI (MS authentication check). 

e) A C_AHOY PDU from SUPLI to upload supplementary data from calHng MS. 

f) A Channel Grant PDU(s) for this call. 

NOTE: A multi-block UDT cannot transfer all Service Options to the called party. If the Service Options are 

essential to the operation of the system, a C_AHOY/response and a Multi_block UDT/response may be 
sent to the MS. The two messages may be sent in any order. 
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6.6.3.1 .2 TSCC Response to multi-part packet call setup 

For calls to extended_addresses, the MS requests multi-part addressing by generating a packet data call random access 
request with the Destination Address information element set to a gateway address (PABXI, PSTNI, IPI etc.) and the 
Proxy Flag information element to indicate the number of digits for the extended_address. For the number of dialled 
digits = 1 to 20 the Proxy Flag information element shall be set to O2. For the number of dialled digits = 21 to 44 the 
Proxy Flag information element shall be set to I2. The PDUs that shall represent a valid response to the voice call 
multi-part part voice service random access request are: 

a) An acknowledgement PDU C_NACKD, C_WACKD(reason=Wait). 

b) A C_AHOY PDU from PABXI, PSTNI, LINEI, DISPATI for the calHng MS to send the extended_address 
information. 

c) A C_AHOY PDU from SUPLI for the calling MS to send supplementary data (see clause 6.5). 

For b) the TSCC shall then invoke the UDT procedure by sending a C_AHOY to the calling MS to send the 
extended_address information. For a call to the PABX or PSTN the extended_address information shall be BCD digits. 
The Proxy Flag information element in the C-AHOY PDU shall be copied from the Proxy Flag information element 
received from the MS C_RAND PDU. 

For c) the TSCC shall then invoke the UDT procedure by sending a C_AHOY to the calling MS to send the 
supplementary data. The format of the supplementary data is specified in the UDT. 

If the TSCC does not successfully receive the UDT from the MS, the TSCC may repeat the C_AHOY or transmit a 
C_NACKD to indicate failure of the call. 

6.6.3.1 .3 Acknowledgements sent on the TSCC to the calling MS (packet) 

The TSCC may send acknowledgement PDUs following the random access data packet service request to indicate the 
progress of the call, to terminate the call. If the TSCC sends a PDU to indicate the progress of a call it shall start a 
waiting timer TP_Timer. (The calling party MS maintains a similar timer). 

a) Progress PDUs are: 

1) C_WACKD: Intermediate acknowledgement. More PDUs to follow. 

2) C_QACKD: Called MS engaged in another call. 

3) C_QACKD: Call is queued because the resource is in use at the moment. 

b) Termination PDUs are selected from an appropriate Reason information element in a C_NACKD PDU 
(see clause 7.2.8): 

1) C_NACKD. 

c) If the TS has previously accepted a call diversion indicating that this type of service request be directed to 
another called party, the TSCC shall invoke the UDT and send a UDT Head + Appended data to the calling 
party. 

6.6.3.1 .4 Radio Check for packet 

For calls to individual MS, the TSCC shall check that the called party is in radio contact and shall accept the call before 
a payload channel is allocated. The radio check may also indicate that the called party data terminal equipment is ready. 

The TSCC may check availability of the called party by: 

a) Sending a C_AHOY PDU to that called party. 

b) Sending a Multi-block UDT with supplementary data (if the supplementary data service is active for this call). 
If a response is not received from the calling party the TSCC may repeat the C_AHOY. 
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The availability check demands a response from the called party: 

• If the response is C_NACKU, the TSCC shall send an appropriate call failed response to the calling MS and 
echo the Reason in the C_NACKD PDU. 

• If the response is C_ACKU(Reason=Message_ Accepted), the TSCC shall progress the service request and 
allocate a payload channel by transmitting appropriate Channel Grant PDUs. 

For calls to packet talkgroups the TSCC may check that at least one member of the talkgroup is listening to the TSCC 
by sending a C_AHOY addressed to the talkgroup. 



6.6.3.1.5 



Availability Check for Packet Calls connected through Gateways 



For calls connected through gateways the TS equipment may wait until the destination is ready before allocating the 
payload channel. For example a TS waits until PSTN equipment has linked the data terminal before sending Channel 
Grant PDUs. 



6.6.3.2 



Packet Data Gall Procedures for MS 



A MS is able to request a packet data call service to another individual MS or a talkgroup using a single-part service 
request. For a packet data service requested to extended_addresses through a gateway the MS requests a multi-part 
service request. For multi-part service requests the MS sets the gateway address as the called party. The full destination 
address is then provided by the MS to the TSCC by the UDT procedure. 

A MS requests a packet data service by sending a C_RAND random access request complying with the random access 
procedures in clause 6.2. The information elements in the random access request are passed to the CC layer - set 
appropriately as prescribed in table 6.37. 

Table 6.37: C RAND information elements for a Packet Data Call Service 



Information 
Element (I.E) 


I.E 
Length 


length 


Alias 


Value 


Remark 


Service_Options 


7 


1 


EMERG 


02 


Non-emergency service 


I2 


Emergency service 


1 




02 


Privacy (see note 1 ) 


1 


SUPED_SV 


02 


No Supplementary Data Transfer Service 
required for this call 


I2 


Supplementary Data Transfer Service 
requested for this call 


1 


HLRATE 


02 


MS requests single slot payload channel 
data timing 


I2 


MS requests dual slot payload channel data 
timing 


1 


OVCM_SV 


02 


Non-OVCM call 


I2 


OVCM call 


2 


PRIORTY_SV 
(see note 2) 


002 


Normal (low) priority 


012 


Medium Priority 


102 


High Priority 


112 


Highest Priority 


Proxy Flag 


1 




PROXY 


02 


Number of Extended BCD digits for 
addressing through a PSTN/PABX gateway 
= 1 to 20. For IP gateway 
extended address is IPV4 


I2 


Number of Extended BCD digits for 
addressing through a PSTN/PABX gateway 
= 21 to 44. For IP gateway 
extended address is IPV6 
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Information 
Element (I.E) 


I.E 
Length 


length 


Alias 


Value 


Remark 


Appended_Supplem 
entary_Data 


2 




SUPED_VAL 


Value 


Number of appended UDTs required to 
transport supplementary data 


Appended_Short 
Data 


2 




SDATA_VAL 


OO2 


Not Applicable for Packet Data 


Service_Kind 


4 




IND_D_SRV 


001 O2 


Individual packet data Call Service 


GRP_D_SRV 


OOII2 


Talkgroup packet data Call Service 


Target_address or 
Gateway 


24 






Value 


Target Address (see note 3) 


Source address 


24 






Value 


Individual Address of the requesting MS 


NOTE 1 : Privacy is not defined in the present document. 
NOTE 2: If EMERG = 1 ^ then PRIORTY_SV is set to OO2. 

NOTE 3: If Service_Kind = IND_D_SRV then Target_Address represents an Individual address. 
If Service Kind = GRP D SRV then Target Address represents a Talkgroup. 



6.6.3.2.1 



Initiating a single-part packet data call service 



For a packet data service request to an individual MS or talkgroup, the destination address is completely expressed by 
the Target Address information element in the random access PDU. The Service_Kind specifies if the data packet call 
service is addressed to an individual address or a talkgroup. 

6.6.3.2.2 Response to the single-part packet service request 

MS shall accept the following PDUs as valid response to the single-part data packet service request: 

a) an acknowledgement C_WACKD, C_QACKD, C_NACKD; 

b) a C_AHOY from the calling party MS ID - called party radio check; 

c) a Channel Grant PDU; 

d) if the Service_Options SUPED_SV = I2 a C_AHOY from SUPLI to upload the supplementary data from the 
calling MS; 

e) a UDT Head + appended blocks UDT Header PDUs Source_Address=DIVERTI, Embedded_Flag = 1 . 

6.6.3.2.3 Response to the multi-part packet data service request 

MS shall accept the following PDUs as valid response to the multi-part data packet service request: 

a) an acknowledgement C_WACKD, C_QACKD, C_NACKD; 

b) a C_AHOY PDU from PABXI,PSTNI,LINEI,DISPATI to upload the extended_address: 

1) for a call to the PABX/PSTN/LINEI,DISPATI, a C_AHOY to upload the dialled digits; 

2) if the Service_Options SUPED_SV = I2 a C_AHOY from SUPLI to upload the supplementary data from 
the calHng MS. 

NOTE: For b), if the Data packet Call Service Request requires extended_address information and the calling MS 
has selected the Supplementary Data in the Service option, the TSCC uploads the information in two 
steps. The order in which the information is uploaded is not prescribed because the C_AHOY specifically 
indicates which UDT inbound procedure has been invoked by setting appropriate unambiguous 
information elements in the C_AHOY PDU. 
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6.6.3.2.4 Acknowledgements received by the calling MS (packet data) 

At some time after sending the packet data service request random access PDU the calling MS may receive an 
acknowledgement. On receiving the acknowledgement, the MS shall start or restart a waiting timer, TP_Timer. (The 
TSCC maintains a similar timer.) 

The MS shall take the actions prescribed: 

a) Progress PDUs for a single-part data packet call Service Request are: 

1) C_WACKD: Intermediate acknowledgement. More PDUs to follow. The MS shall wait TP_Timer for 
further signalling and may indicate a possible delay to the calling MS; 

2) C_QACKD (Reason=Queued_for_Busy): Called MS engaged in another call. The MS shall wait 
TP_Timer for further signalling and may indicate a possible delay to the calling MS; 

3) C_QACKD (Reason=Queued_for_Resource): Call is queued because the resource is in use at the 
moment. The MS shall wait TP_Timer for further signalling and may indicate a possible delay to the 
calling MS. The MS may choose to differentiate between 1), 2) and 3) by providing the calling MS with 
a particular indication for each of the conditions. 

b) Termination PDUs are selected from an appropriate Reason information element in a C_NACKD PDU (see 
clause 7.2.8): 

1) C_NACKD: Call refused and terminated. The C_NACKD PDU provides a versatile range of Reason 
codes to indicate to the calling party why the Service request was terminated. The calling party shall 
return to the idle state. If the call was rejected by the calling party, the termination PDU sent by the TS 
shall be a C_NACKD(mirrored_reason): 

6.6.3.2.5 Availability Check to the called MS (packet data) 

For an individual MS address call set-up, the called MS shall receive a radio check to which it shall respond with an 
appropriate acknowledgement. 

• The called party shall respond C_NACKU, if it cannot accept the call or its data terminal equipment is not 
ready (the TSCC shall send an appropriate call failed response to the calling MS (mirrored_reason)). 

• The calling party shall respond C_ACKU (Reason=Message_Accepted), if the call is accepted (the TSCC shall 
progress the service request and allocate a payload channel by transmitting appropriate Channel Grant PDUs). 

6.6.3.2.6 Payload Channel Allocation 

MS shall check the address information elements received in Packet Data Channel Grant PDUs. If it is determined that 
the Channel Grant PDU is applicable then it shall retune to the indicated physical/logical payload channel to commence 
the Packet Data Service. 

a) For Private Packet Data Channel Grant CSBK PDU: 

1) If an MS receives a Private Channel Grant PDU where either the Source Address or the Target Address 
information element matches its individual address then that PDU is applicable. 

b) Talkgroup Packet Data Channel Grant CSBK PDU: 

1) If an MS receives a Talkgroup Channel Grant PDU with the Target Address information element 
matching one of its talkgroup addresses then that PDU is applicable. 

2) If an MS receives a Talkgroup Channel Grant PDU with the Source Address matching its individual 
address then that PDU is applicable. 
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6.6.3.3 



Procedures for the Packet Data Payload Channel 



MSs are directed to a Packet Data payload physical/logical channel on the TSCC. When the Packet Data call is 
terminated by either the TS or MS, the MS shall return to the TSCC. When a physical channel has been assigned, data 
PDUs of arbitrary length are transferred over the DMR Air Interface using the packet technique described in 
TS 102 361-1 [5] andTS 102 361-3 [7]. 

A Packet Data call may continue unless the call is terminated by a) the MS or b) the TS or c) terminated prematurely as 
a result of the expiry of an overall payload call payload timer). 

A physical channel may be configured such that two independent payload channels are available to the system (single 
slot transmission mode) or a high-speed data mode (dual slot transmission mode) where both logical channels are 
combined to provide a high-speed Packet Data service. The particular data speed configuration is requested by the 
calling MS and signalled to the parties by the Channel Grant PDUs. 

The procedures for TS/MS behaviour on the Packet Data payload channel are described in TS 102 361-3 [7]. In the 
trunked environment however, additional call maintenance PDUs are exchanged between MS and TS in addition to the 
PDUs described in TS 102 361-3 [7]. 

When active on a payload channel, the TS shall transmit the CACH in the same form as described in TS 102 361-2 [6], 
clause 7.1.3.2). 

The system may direct a number of independent Packet Data calls to the same Packet Data channel. MSs may then 
share that channel, but it must be noted that while MS are away from the TSCC, they are unable to receive new calls. 
New Packet Data calls directed to a MS that is active on a Packet Data channel may either be queued by the system or 
such a call may be directed to the Packet Data channel and share the channel with other ongoing calls. 

If the destination is an ipv4 or ipv6 address, the destination address shall have been specified by the calling party as a 
function of a multi-part call set-up. Therefore the when the MS is directed to the packet data payload channel the system 
will have the full destination address. The MS may therefore set the destination address to IPI for all packet data items. 

If an MS receives a packet data call set-up from an ipv4 or ipv6 address, the UDT protocol is able to send the full 
calling party IP address as part of the call set-up using the supplementary data transfer service. The system may then use 
IPI as the source address for the packet data call. 



6.6.3.3.1 



TS Procedures for the Packet Data Payload Channel 



If a new physical channel is allocated on the TSCC, the CCL_BS shall start both the CCL_1 and CCL_2 processes as 
described in TS 102 361-2 [6], clause 5.1.1.1.3) and start the Packet Data payload timer T_PACKET_TIMER. 



6.6.3.3.1.1 



MS radio check 



The TS may poll an individual MS to check if the MS is active on the payload channel by transmitting a P_AHOY PDU 
with the information elements set as follows. 

The TSCC transmits a P_AHOY with the information elements as illustrated in table 6.38. 

Table 6.38: P_AHOY information elements 
for Packet Data service individual radio check 



Service_Options_Mirror 


7 


000 OOOO2 


Service_Kind_Flag 


1 


O2 


Ambient Listening Service 


1 


O2 - Not Applicable 


IG 


1 


O2 - The Target address is an MS individual ID 


Appended_Blocks 


2 


OO2 


Service_Kind 


4 


Individual Packet Call Service - 001 O2 


Target address 


24 


Individual Address of Called MS 


Source Address or Gateway 


24 


TSI 
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The response is C_ACKU (Reason=Message_ Accepted). 

The TS may also poll a talkgroup to check if at least one member of the talkgroup is active on the payload channel by 
transmitting a P_AHOY PDU with the information elements set as follows. 

The TSCC transmits a P_AHOY with the information elements as illustrated in table 6.39. 

Table 6.39: P_AHOY information elements 
for packet service talkgroup radio check 



Service_Options_Mirror 


7 


000 OOOO2 


Service_Kind_Flag 


1 


O2 


Ambient Listening Service 


1 


O2 - Not Applicable 


IG 


1 


I2 - The Target address is a talkgroup 


Appended_Blocks 


2 


OO2 


Service_Kind 


4 


Talkgroup Packet Call Service - OOII2 


Target address 


24 


Address of the talkgroup 


Source Address or Gateway 


24 


TSI 



The response is P_ACKU (Reason=Message_ Accepted). If more than one MS makes a response to this PDU, it is Hkely 
that the TS will be unable to decode it because of collisions. The purpose of this procedure is to determine if any 
talkgroups are active therefore the TS may use the presence of the burst for the result of the talkgroup radio check. 



6.6.3.3.1.2 



Authentication Check 



The authentication procedures are identical to the authentication procedures described in clause 6.4.8.2 but with the 
C_AHOY PDU replaced by a P_AHOY PDU. 



6.6.3.3.1.3 



Disabling/enabling a users transmission 



The TS may at any time send a P_PROTECT (Protect_Kind=DIS_PTT) addressed to an individual MS, talkgroup, or 
All_Unit ID 15 (see TS 102 361-1 [5], annex A) to disable all MS transmissions for the remainder of the call. Since the 
P_PROTECT PDU is unacknowledged the PDU may be repeated. 

The TS may also at any time send a P_PROTECT (Protect_Kind=EN_PTT) addressed to an individual MS, talkgroup, 
or AlLUnit ID15 (see TS 102 361-1 [5], annex A) to enable the users transmission. Since the P_PROTECT PDU is 
unacknowledged the PDU may be repeated at layer 2. 



6.6.3.3.1.4 



Swapping the call to a replacement Packet Data payload channel 



The TS may send Channel Grant PDUs to move MS already active to an alternative packet data payload channel. If MS 
had previously received a P_PROTECT to disable its transmissions, the transmissions shall be re-enabled on the 
replacement packet data payload channel. The replacement packet data channel shall be with the same slot 
configuration (single or dual slot). If the packet data payload channel supports multiple simultaneous calls then channel 
grant PDUs must be transmitted for each of the MS or talkgroups currently active on the payload channel. 

6.6.3.3.1 .5 Clearing down the packet data channel 

The TS shall clear down the parties involved in all payload calls if: 

a) the relevant overall payload call timer T_PACKET_TIMER expires; 

b) the TS receives a P_MAINT (Maint_Kind = DISCON) PDU; 

c) the TS detects by any other means that the call has ended (e.g. PSTN destination on hook); 

d) the TV_Hangtime interval timer expires. 

The TS shall clear down the data call by transmitting P_CLEAR PDU(s). Since this PDU is not acknowledged it may be 
repeated at layer 2. 
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6.6.3.3.1 .6 Clearing down a particular MS or talkgroup 

The TS is able to clear down the parties involved in a payload call if: 

a) the TS receives a P_MAINT (Maint_Kind = DISCON) PDU; 

b) the TS detects by any other means that the packet call has ended. 

The TS response to an applicable P_MAINT(Maint_Kind-DISCON) is P_NACKD. 

The TS may selectively clear a MS by transmitting a P_AHOY with information elements set as table 6.40. 

Table 6.40: P_AHOY information elements to clear an individual MS from a packet payload channel 



Service_Options_Mirror 


7 


000 OOOO2 


Service_Kind_Flag 


1 


O2 Indicates that the target is an Individual Address 


Ambient Listening Service 


1 


O2 - Not Applicable 


IG 


1 


O2 - The Target address is an MS individual ID 


Appended_Blocks 


2 


OO2 


Service_Kind 


4 


Cancel Call Service - 1 1 1 12 Service_Kind_Flag - O2 


Target address 


24 


Individual Address of MS 


Source Address or Gateway 


24 


TSI 



The permitted response is P_ACKU (Message_ Accepted). 

The TS may selectively clear a talkgroup by transmitting a P_AHOY with information elements set as table 6.41. 

Table 6.41 : P_AHOY information elements to clear a talkgroup from a packet payload channel 



Service_Options_Mirror 


7 


000 OOOO2 


Service_Kind_Flag 


1 


^2 Indicates that the target is a talkgroup 


Ambient Listening Service 


1 


O2 - Not Applicable 


IG 


1 


I2 - The Target address is a talkgroup 


Appended_Blocks 


2 


OO2 


Service_Kind 


4 


Cancel Call Service - 1 1 1 12 Service_Kind_Flag - O2 


Target address 


24 


talkgroup 


Source Address or Gateway 


24 


TSI 



The permitted response is P_ACKU (Message_ Accepted). 



6.6.3.3.2 



6.6.3.3.2.1 



MS Procedures for the Packet Data Payload Channel 



MS receives an MS radio check 



If an MS receives a P_AHOY to its individual address with information elements set as table 6.40, then it shall respond 
with a P_ACKU (Reason=message_accepted). 

If an MS receives a P_AHOY to it is the talkgroup address previously transmitted in the Channel Grant PDU that 
directed this MS to the payload channel (information elements set as table 6.41) then it shall respond with a P_ACKU 
(Reason=message_accepted). 



6.6.3.3.2.2 



MS receives a Authentication Check Challenge 



The authentication procedures are identical to the authentication procedures described in clause 6.4.8.2 but with the 
authentication response C_ACKU PDU replaced by a P_ACKU PDU. 
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6.6.3.3.2.3 Disabling/enabling a user transmission 

If the MS receives a P_PROTECT (Protect_Kind=DIS_PTT) addressed to its individual address, or to it is talkgroup 
address previously transmitted in the Channel Grant PDU, or All_Unit ID 15 (see TS 102 361-1 [5], annex A), the MS 
shall disable it is transmissions. 

If the MS receives a P_PROTECT (Protect_Kind=EN_PTT) addressed to its individual address, to it is talkgroup 
address previously transmitted in the Channel Grant PDU, or All_Unit ID15 (see TS 102 361-1 [5], annex A), the MS 
shall re-enable it is transmissions. 

6.6.3.3.2.4 MS receives a Channel Grant PDU(s) 

If a MS receives an applicable Channel Grant addressed to its individual address or to it is talkgroup address previously 
transmitted in the Channel Grant PDU, then it shall retune to the designated physical/logical channel. If the PTT was 
disabled prior to receiving the Channel Grant, the PTT shall be re-enabled unless this MS was the recipient of a 
broadcast call set-up or a call to All_Unit ID. 

6.6.3.3.2.5 End of call 

The MS shall signify the end of the call by transmitting a number of P_MAINT (Maint_Kind = DISCON). The MS 
shall send the P_MAINT PDUs consecutively then return to the control channel acquisition procedures (it is suggested 
that the TSCC initially sampled is the TSCC that transferred the call to the pay load channel). 

6.6.3.3.2.6 MS receives P_GLEAR 

If a MS receives an applicable P_CLEAR PDU then it shall abandon the payload channel and move to the TSCC 
indicated by the Logical Physical Channel Number PDU. 

6.6.3.3.2.7 MS receives a selective clear P_AHOY 

If a MS receives an individually addressed P_AHOY, Service_Kind=llll2, Service_Kind_Flag=02 information 
element then it shall send a P_ACKU (Reason=Message_Accepted), abandon the payload channel and return to the 
control channel acquisition procedures (it is suggested that the TSCC initially sampled is the TSCC that transferred the 
call to the payload channel). 

If a MS receives a P_AHOY, Service_Kind=l 1 1 12, Service_Kind_Flag=l2 information element addressed to it is 
talkgroup address previously transmitted in the Channel Grant PDU the talkgroup then it shall send a P_ACKU 
(Reason=Message_Accepted) abandon the payload channel and return to the control channel acquisition procedures (it 
is suggested that the TSCC initially sampled is the TSCC that transferred the call to the payload channel). 

6.6.3.3.2.8 Time out on the Payload Channel 

A MS shall maintain a number of timers while active on a packet data payload channel. 

a) Inactivity timer: 

A MS shall measure the length of time the MS is unable to detect adequate signal quality. If the MS fails 
to detect adequate signal quality for a continuous time TD_Inactive, the MS shall assume that the call has 
ended and return to the control channel acquisition procedures without sending any call termination 
signalling (it is suggested that the TSCC sampled is the TSCC that transferred the call to the payload 
channel). 

b) Item Duration timer: 

A MS shall maintain the maximum item duration timer TD_Item. If the MS reaches the maximum item 
duration TD_Item, the MS shall transmit a Terminator with LC, discontinue the item and indicate to the 
higher layers that the item was not successfully transmitted. 
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c) An overall payload call timer: 

If the overall packet data payload call timer T_PACKET_TIMER expires, the MS shall transmit a 
number(N_Maint) of P_MAINT PDUs consecutively then return to the control channel acquisition 
procedures (it is suggested that the TSCC sampled is the TSCC that transferred the call to the payload 
channel) If the MS was sending speech frames when the overall data packet payload call timer expires, 
the MS shall transmit a Terminator with LC prior to transmitting the P_MAINT PDUs. 

6.6.4 Short Data Message Procedure 

The Short Data Message service enables data to be transmitted between DMR entities using the control channel. Up to 
462 bits of data may be transported using this service formatted in a number of formats including binary, BCD, 7 bit 
text, 8 bit characters, NMEA (lEC 61162-1 [8]), Unicode, IP, authentication and manufacturer specific proprietary 
formats. 



The Short Data Message procedure uses the multi-part call set-up. A MS may send a Short Data Message to an MS, a 
talkgroup, the PSTN or PABX, a line connected gateway, a dispatcher gateway, or all_MS (if the TSCC permits it). ^ 
TSCC may also transmit a short data message from a gateway addressed to an individual MS or talkgroup. 
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Figure 6.44: Example of a Short Data Message transfer 

Figure 6.44 shows an example of a short data message transfer from MS to MS: 

a) MS (A) calculates the number of appended UDTs needed to transmit the short data. In this example, two 
appended UDTs are required; 

b) "A" is the random access C_RAND PDU. The called party is MS(B) and Service_Kind set to 'Short Data' and 
the Appended_Short_Data PDU to the number of data blocks needed to transport the short data; 

c) "B" is a C_AHOY PDU from SDMI that request MS(A) to transport the short data using the UDT mechanism; 

d) "C" is the inbound phase consisting of a Multi-block UDT header + appended data; 

e) "D" is the outbound phase consisting of a Multi-block UDT header + appended data; 

f) "E" is the acknowledgement from MS(B); 

g) "F" is the final acknowledgement to the calling party MS (A). Note that the acknowledgement is repeated for 
reliability. 

For a call to an extended_address destination the TSCC uses the UDT mechanism to transport the extended_address 
information. In this case the inbound phase shall use two UDT procedures. The PDUs in the C_AHOY PDU indicate 
which UDT inbound transport is requested by unambiguous PDUs in the C_AHOY PDU. 

The maximum number of bits that may be transported by the short data message service is limited by the maximum 
number of appended data UDTs. The Tier III protocol permits up to four appended UDTs. 

For a short data message service to a talkgroup, the called party shall not send a response. The TSCC may repeat the 
outbound phase to improve the probability of a successful message transfer. The TSCC shall send a final 
acknowledgement to the calling unit even though the receipt of the short data message is not certain. 



ETSI 



119 



ETSI TS 102 361-4 V1.3.1 (2010-06) 



The timing for the inbound and outbound phases is not prescribed in the present document. Figure 6.26 shows examples 
of other appHcable short data message deHvery. 

In the first example, the UDT Header and appended UDTs are re-transmitted by the TSCC as soon as they have been 
received. This timing has the advantage of minimizing end-to-end latency (between two subscriber units); however, 
messages received with detectable but uncorrectable errors on the inbound phase result in messages containing 
uncorrectable errors on the outbound path which is essentially wasted bandwidth. The whole inbound and outbound 
phase would have to be repeated. 

If the inbound phase is completed in its entirety as illustrated in the second example (and in figure 6.44), if 
uncorrectable errors are detected, that phase may be repeated before moving to the outbound phase. However, 
end-to-end latency (between the two MS) is sacrificed. 
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Figure 6.45: More Examples of a Short Data Message transfer 



Short Data Procedures for the TSCC 



A MS requests a Tier III short data message service by generating a random access request PDU with the Target 
Address set to: 

a) an individual MS address; 

b) a talkgroup MS address; 

c) a gateway address (a UDT to transport the extended destination address from the MS). 

When the TSCC responds to the random access request, it shall start a timer (TNP_Timer). This timer shall be refreshed 
if the TSCC sends further call progress messages to the calling party. 



6.6.4.1.1 



TSCC Response to a call to an individual MS or talkgroup 



When a random access short message service PDU is received on the TSCC, the TSCC shall send a response in 
accordance with the random access procedures prescribed in clause 6.2. 

The PDUs that represent a valid response to the short data message service random access request to a MS or talkgroup 
are: 

a) an acknowledgement PDU C_NACKD, C_QACKD, C_WACKD; 

b) a UDT Head + appended block(s) (short data call is diverted); 

c) a C_AHOY PDU from AUTHI (MS authentication check); 
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d) a C_AHOY PDU from SDMI instructing the calling MS to transport its short data message using the UDT 
mechanism; 

e) a C_AHOY PDU from SUPLI instructing the calling MS to transport supplementary data using the UDT 
mechanism; 

f) for a call to an extended_address, A C_AHOY PDU from PABXI,PSTNI,LINEI,DISPATI,IPI instructing the 
calling party to send its extended_address (such as PSTN, PABX etc.) using the UDT mechanism. 

NOTE: c), d) and e) may be performed in any order. 



6.6.4.1.2 



TSCC Response to a call to an extended_address destination 



When a random access short message service PDU is received on the TSCC, the TSCC shall send a response in 
accordance with the random access procedures prescribed in clause 6.2. 

The PDUs that represent a valid response to the short data message service random access request to an 
extended_address are: 

a) an acknowledgement PDU C_QACKD, C_WACKD; 

b) a C_AHOY PDU from SDMI instructing the calling MS to transport its short data message using the UDT 
mechanism; 

c) a C_AHOY PDU from SUPLI instructing the calling MS to transport supplementary data using the UDT 
mechanism; 

NOTE: b) and c) may be performed in any order. 

The gateway PDUs for C_AHOY PDUs to support short data message services are prescribed in table 6.42. 

Table 6.42: C_AHOY information elements for short data message service to a gateway 



Action 


Gateway 
Address 


Remark 


Send PSTN digits for the short data destination 


PSTNI 


The calling party shall uplink BCD dialled digits 


Send PABX digits for the short data destination 


PABXI 


The calling party shall uplink BCD dialled digits 


Send LINE digits for the short data destination 


LINE! 


The calling party shall uplink BCD dialled digits 


Send dispatcher digits for the short data destination 


DISPATI 


The calling party shall uplink BCD dialled digits 


Uplink IP address for the short data destination 


IPI 


The calling party shall uplink the IPV4 or IPV6 address 



d) C_NACKD: Call refused and terminated. The calling party shall return to the idle state. If the call termination 
was the result of the called party refusing the call, the C_NACKD shall use a mirrored_reason; 



e) if the TS has previously accepted a call diversion indicating that this type of service request be directed to 
another called party, a UDT Head + Appended data indicating the diverted address. 



6.6.4.1.3 



Availability Check to the called MS (short data) 



For calls to individual MS, the TSCC may check that the called party is in radio contact before downloading the short 
data. 

The TSCC may check availability of the called party by: 

a) Sending a C_AHOY PDU to that called party. 

b) Sending a Multi-block UDT with supplementary data (if the supplementary data service is active for this call). 
If a response is not received from the calling party the TSCC may repeat the C_AHOY. 
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The availability check demands a response from the called party: 

• If the response is C_NACKU, the TSCC shall abandon the short message call send an appropriate call failed 
response to the calling MS and echo the mirrored_reason in the C_NACKD PDU. 

• If the response is C_ACKU (Reason=Message_Accepted), the TSCC shall progress the service request and 
download the short data message using the UDT mechanism. 



6.6.4.1.4 



Final acknowledgement to the calling party 



In the outbound phase, the TSCC downloads the short data message to the called party. If the recipient is an individual 
MS an acknowledgement shall be received on the TSCC. For a short data message service to a talkgroup the outbound 
phase may be repeated but no acknowledgement shall be expected. 

The TSCC shall send an appropriate acknowledgement to the calling party to indicate the outcome of the short data 
transfer request. The acknowledgement shall use a mirrored_reason code. 



6.6.4.2 



Short Data Message procedures for MS 



A MS requests a short data message call service to another individual MS or a talkgroup or gateway using a multi-part 
service request. For calls to an extended_address, the transport of the extended_address and the short data message is 
uploaded by two separate UDT transfers. 

A MS requests a short data service by sending a C_RAND random access request complying with the random access 
procedures in clause 6.2. The PDUs in the random access request are passed to the CC layer - set appropriately as 
prescribed in table 6.43. 

Table 6.43: C_RAND information elements for a Short Data Message Service 



Information 
Element (I.E) 


I.E 
Length 


length 


Alias 


Value 


Remark 


Service_Options 


7 


1 


EMERG 


Not applicable - O2 


1 




02 


Privacy (see note 1 ) 


1 


SUPED_SV 


02 


No Supplementary Data Transfer Service 
required for this call 


I2 


Supplementary Data Transfer Service 
requested for this call 


1 


BCAST_SV 


02 


Not applicable - O2 


1 


OVCM_SV 


02 


Not applicable - O2 


2 


PRIORTY_SV 


02 


Not applicable - O2 


Proxy Flag 


1 




PROXY 


02 


Number of Extended BCD digits for 
addressing through a gateway = 1 to 20 


I2 


Number of Extended BCD digits for 
addressing through a gateway = 21 to 44 


Appended_Supplem 
entary Data 


2 




SUPED_VAL 


Value 


Number of appended UDTs required to 
transport supplementary data 


Appended_Short 
Data 


2 




SDATA_VAL 


OO2 


Number of appended UDTs required 
transport short data 


Service_Kind 


4 




IND_SD_SRV 


OIOO2 


Individual Short Data Gall Service 


GRP_SD_SRV 


OIOI2 


Talkgroup Short Data Call Service 


Target_address or 
Gateway 


24 






Value 


Target Address (see note 2) 


Source address 


24 






Value 


Individual Address of the requesting MS 


NOTE 1 : Privacy is not defined in the present document. 

NOTE 2: If Service_Kind = IND_SD_SRV then Target_Address represents an Individual address. 
If Service_Kind = GRP_SD_SRV then Target_Address represents a Talkgroup. 
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6.6.4.3 Initiating a Short Data Message service 

For a short data message service request to an individual MS or talkgroup, the destination address is completely 
expressed by the Target Address information element in the C_RAND random access PDU. The Service_Kind specifies 
if the Short Data Message call service is addressed to an individual address or a talkgroup. For calls to a gateway 
addresses the Target_address or Gateway information element in the C_RAND is set to the gateway address. 

The MS shall attempt access until it receives a valid response, or the service is cancelled by the user, or the attempt fails 
by sending the maximum number of random access PDUs or the random access timer expires. 

6.6.4.4 Response to a random access short data message 

The calling MS shall accept the following PDUs a valid response to the SDM random access request: 

a) an acknowledgement PDU C_NACKD, C_QACKD, C_WACKD; 

b) a UDT Head + appended block(s) (short data call is diverted); 

c) a C_AHOY PDU from SDMI instructing the calling MS to transport its short data message using the UDT 
mechanism; 

d) a C_AHOY PDU from SUPLI instructing the calling MS to transport supplementary data using the UDT 
mechanism; 

e) for a call to an extended_address, A C_AHOY PDU from PABXI,PSTNI,LINEI,DISPATI,IPI instructing the 
calling party to send its extended_address using the UDT mechanism. 

NOTE: c), d) and e) may be performed in any order. 

6.6.4.5 Acknowledgements received by the calling MS 

When the C_RAND PDU has been transmitted by the calling party, an initial response may be received by the calling 
party as specified in clause 6.6.4.4. 

At any time further PDUs may be sent to the calling party as follows: 

a) a C_NACKD at any time to indicate the call has failed. The Reason information element shall be set to 
indicate the reason for the call failure; 

b) a C_WACKD if more signalling will follow; 

c) after the short data message has been successfully transported, C_ACKD PDU(mirrored_reason). 

If a C_NACKD is received, the calling MS shall abandon the short data message call and return to the idle state. 
Any applicable call progress acknowledgement received shall restart the TNP_timer. 

6.6.4.6 Timeout waiting for further signalling 

A MS waiting for further signalling shall abandon the short data message service and return to the idle state if the 
TNP_Timer expires. 

6.6.4.7 MS receiving a short data message 



If a MS receives a multi block UDT Head PDU with the Target Address matching its individual address, it shall 
respond with an appropriate acknowledgement. The Appended_B locks information element in the UDT header 
indicates the number of appended UDT blocks. 

If a MS receives a multi block UDT Head PDU with the Target Address matching a talkgroup, it shall accept the 
information contained in the appended blocks, but shall transmit no response. 
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6.6.4.8 Short Data Message procedure MSC 

Figure 6.46 illustrates the Short Data Message procedure to an individual MS or Talkgroup as defined in clause 6.6.4. 



MSC TS_ShortDataMessageProcedure 


TS_CCL DLL 


PL 




Rx_C_RAND 


Rx_CSBK 




CSBK 


(C_RAND) 






( Service_Kind=IND_SD_SRV) 
Tx_C_AHOY 


AB=0 is number 
of appended blocks 
is1 




(AB=0) 

Rx_C_UDTHD 






(C_AHOY) 


CSBK 










Receive the short 
data message on 
the uplink 




(C_UDTHD) 
CSBK 


(AB=0) 
Rx_C_UDT 






CSBK 


(C_UDT) 








(C_UDT) 
Tx_C_UDTHD 


Transmit the short 
data message on 
the downlink 




Tx_UDT 






(C_UDTHD) 
CSBK 






Rx_C_ACKU 


(C_UDT) 


CSBK 








Receive 

acknowledgement 
on uplink. 




(C_ACKU) 






-^ 

(C_ACKU) 







Figure 6.46: Short Data Message MSC 



6.6.5 Short Data Polling Service 



The Short Data Polling Message service enables data to be polled from MS using the control channel. Up to 288 bits of 
data may be transported using this service formatted in a number of formats including binary, BCD, ISO 7 bit text 
(ISO/IEC 646 [11]), ISO 8 bit characters (ISO/IEC 8859 [12]), NMEA (lEC 61162-1 [8]) formatted location data, and 
manufacturer specific proprietary formats. 

NOTE: Calling and polled MSs will pre-arrange the number of appended UDTs required to transport the polled 
data. 

The Short Data Message polling procedure uses the single-part call set-up. 
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Figure 6.47: Example of a Short Data Polling transfer 

Figure 6.47 shows an example of a short data polHng service: 

a) MS (A) specifies the number of appended UDTs for the polled short data. In this example, one appended UDT 
is required; 

b) "A" is the random access C_RAND PDU. The target address is set to the polled party, Service_Kind set to 
'Short Data Polling' and the Appended_Short_Data information element to the number of data blocks to 
transport the polled short data; 

c) "B" is a C_AHOY PDU from SDMI that requests MS(B) to transport the short data using the UDT 
mechanism; 

d) "C" is the inbound phase consisting of a Multi-block UDT header + appended data; 

e) "D" is the outbound phase consisting of a Multi-block UDT header + appended data; 

f) "E" is the final acknowledgement from MS(A). 

The maximum number of bits that may be transported by the short data message polling service is limited by the 
maximum number of appended data UDTs. The Tier III protocol permits up to four appended UDTs. 
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Figure 6.48: Example of short data polling from a gateway 

Figure 6.48 shows a short data polling transfer from a gateway to a MS. The TSCC requests the short data by 
transmitting a C_AHOY PDU from SDMI addressed to MS(A). MS(A) responds with the UDT head + short data. 



6.6.5.1 



Short Data Polling Procedures for the TSCC 



A MS requests a Tier III short data polling message service by generating a random access request PDU with the Target 
Address set to an individual address. 

When the TSCC responds to the random access request, it shall start a timer (TNP_Timer). This timer shall be refreshed 
if the TSCC sends further call progress PDUs to the calling party. 
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6.6.5.1 .1 TSCC Response to a poll request from an MS 

When a random access short data poll service PDU is received on the TSCC, the TSCC shall send a response in 
accordance with the random access procedures prescribed in clause 6.2. 

The PDUs that represent a valid response to the short data polling service random access request to a MS or talkgroup 
are: 

a) an acknowledgement PDU C_NACKD, C_QACKD, C_WACKD; 

b) a C_AHOY PDU from SDMI instructing the polled MS to transport supplementary data using the UDT 
mechanism; 

c) A C_AHOY PDU from AUTHI (MS authentication check). 

If the polled MS has diverted its calls the response shall be C_NACKD (Reason^ Div_Cause_Fail). 

6.6.5.1 .2 Availability Check to the called MS (short data poll) 

The TSCC may check that the called party is in radio contact before polling the MS for the short data. 

The TSCC may check availability of the polled party by sending a C_AHOY PDU addressed to the polled MS 
individual address. If a response is not received from the calling party the TSCC may repeat the C_AHOY at layer 2. 

The availability check demands a response from the called party: 

a) If the response is C_NACKU, the TSCC shall abandon the short message polling transaction, send an 
appropriate call failed response to the calling MS and echo the Reason in the C_NACKD PDU 
(mirrored_reason) . 

b) If the response is C_ACKU (Reason=Message_Accepted), the TSCC shall progress the service request and 
poll the MS for the short data using the UDT mechanism. 

6.6.5.1 .3 Delivery of the polled data to the calling party 

In the outbound phase, the TSCC downloads the short data polled message to the calling party using the UDT 
mechanism. 

The calling MS shall send an appropriate acknowledgement to the TSCC to indicate the outcome of the short data 
polling request. 

6.6.5.1 .4 Final acknowledgement by the calling party to the TSCC 

The final phase of the polling transaction is the acknowledgement from the calling MS that the polled data was 
successfully received. If the TSCC does not receive a response, it may repeat the outbound phase described in 
clause 6.6.5.1.3. 

6.6.5.1 .5 Short Data Polling procedures from a TSCC gateway 

The short polling service initiated through a gateway is illustrated in figure 6.48. The TSCC transmits a C_AHOY PDU 
from SDMI addressed to an individual MS. The C_AHOY PDU demands a response: 

a) If the response is C_NACKU, the TSCC shall abandon the short message polling transaction. 

b) If the response is a multi-block UDT containing the polled data, the transaction is complete. 
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6.6.5.2 Short Data Polling Message procedures for MS 

A MS requests a short data polling call service to another individual MS, using a single-part service request. 

A MS requests a short data service by sending a C_RAND random access request complying with the random access 
procedures in clause 6.2. The information elements in the random access request are passed to the CC layer - set 
appropriately as prescribed in table 6.44. 

Table 6.44: C_RAND information elements for a Short Data Polling Service 



Information 
Element (I.E) 


I.E 
Length 


length 


Alias 


Value 


Remark 


Service_Options 


7 


1 


EMERG 


Not applicable - O2 


1 




02 


Privacy (see note) 


1 


SUPED_SV 


02 


Not applicable - O2 


4 


POL FMT 


Value 


Format of the polled data 


Proxy Flag 


1 




PROXY 


O2 


Not Defined for the polling service 


Appended_Supplem 
entary Data 


2 




SUPED_VAL 


OO2 


Not Defined for the polling service 


Appended_Short_ 
Data 


2 




SDATA_VAL 


OO2 


Number of UDTs required to transport the 
polled short data 


Service_Kind 


4 




SD_P_SRV 


011 O2 


Short Data Polling Service 


Target_address 


24 






Value 


Polled individual MS address 


Source address 


24 






Value 


Individual Address of the requesting MS 


NOTE: Privacy is not defined in the present document. 



6.6.5.3 Initiating a Short Data Polling service 

For a short data polling service request to an individual MS, the polling MS address is completely expressed by the 
Target Address information element in the C_RAND random access PDU. The Service_Kind specifies the Short Data 
Message call service. 

The MS shall attempt access until it receives a valid response, or the service is cancelled by the user, or the attempt fails 
by sending the maximum number of random access PDUs or the random access timer expires. 

6.6.5.4 Response to a random access short data polling message 

The calling MS shall accept the following PDUs a valid response to the SDM random access request: 

a) An acknowledgement PDU C_NACKD, C_QACKD, C_WACKD. 

b) A C_AHOY PDU instructing the polled MS to transport its short data message using the UDT mechanism. 

6.6.5.5 Final Acknowledgement transmitted by the calling MS 

In the outbound phase, the TSCC downloads the short data polled message to the calling party. Valid responses to the 
TSCC are: 

a) An acknowledgement PDU C_NACKU indicating the transaction has failed. 

b) An acknowledgement PDU C_ACKU indicating the transaction was successful. 

6.6.5.6 Timeout waiting for further signalling 

A MS waiting for further signalling shall abandon the short data polling service and return to the idle state if the 
TNP_Timer expires. 
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6.6.5.7 MS receiving a C_AHOY poll for a short polling message 

If a MS receives a C_AHOY PDU with the Target Address matching its individual address and the 
Service_Kind = Short Data PolHng Service it shall respond with: 

a) A multi block UDT Head PDU with the Target Address matching its calling party (source) address from the 
C_AHOY PDU. The Appended_B locks information element in the UDT header indicates the number of 
appended UDT blocks. 

b) A C_NACKU PDU if the polled MS does not wish to accept the polHng request. 

6.6.6 Status Call Service 

The Status Message service enables data to be transmitted between DMR entities on the control channel. Seven bits of 
data may be transported using this service. The status delivery service transports a status message from the initiator to a 
recipient. The status polling service enables an initiator to request a status message from an addressed entity. Seven bits 
are transported representing 128 status messages. Each status message has a user-defined meaning that is not described 
in the present document. 

Status messages addressed from MS to the TSCC are system messages. 

6.6.6.1 Status Service Delivery Procedure 

The Status Message procedure employs a store and forward mechanism. An MS may send a Status Message to an 
individual MS, talkgroup, the PSTN or PABX, a line connected gateway, a dispatcher gateway or the TSCC. The TSCC 
may also transmit a short data message from a gateway or special identifier addressed to an individual MS or talkgroup. 

6.6.6.1 .1 Status Service Delivery Procedures for the TSCC 

A MS initiates a Status Service by random access addressed to: 

a) An individual MS address (single-part call set-up). 

b) A gateway address that indicates a multi-part call set-up. 

c) The TSCC. 

When the TSCC responds to the random access request it shall start timer (TNP_Timer). This timer shall be refreshed if 
the TSCC sends further call progress messages to the calling party. 

6.6.6.1 .1 .1 TSCC Response to a single part Status Service Delivery call setup 

On receipt of the random access service request the TSCC shall transmit either: 

a) An acknowledgement PDU C_NACKD, C_WACKD (Reason=Wait), C_QACKD addressed to the calling 

MS. 

b) A C_AHOY PDU addressed to the called party for this call to pass the status to the called MS. 

c) A C_AHOY PDU from AUTHI (MS authentication check). 

d) A UDT Head _ appended block(s) (status message service is diverted. If the TS has previously accepted a call 
diversion indicating that this type of service request be directed to another called party, the TSCC shall invoke 
the UDT and send a UDT Head + Appended data to the calling party. 
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6.6.6.1 .1 .2 TSCC Response to a multi part Status Service Delivery call setup 

For calls to extended_addresses, the MS requests multi-part addressing by generating a status call random access 
request with the Destination Address information element set to a gateway address (PABXI, PSTNI, etc.) and the Proxy 
Flag information element to indicate the number of digits for the extended_address. For the number of dialled digits = 1 
to 20 the Proxy Flag information element shall be set to O2. For the number of dialled digits = 21 to 44 the Proxy Flag 
information element shall be set to I2. The PDUs that shall represent a valid response to the multi-part part Status 
service random access request are: 

a) An acknowledgement PDU C_NACKD, C_WACKD(reason=Wait). 

b) A C_AHOY PDU from PABXI,PSTNI,LINEI,DISPATI,IPI for the calling MS to send the extended_address 
information. 

c) A C_AHOY PDU from SUPLI for the calling MS to send supplementary_user data (see clause 6.4.13). 

For b) The TSCC shall then invoke the UDT procedure by sending a C_AHOY to the calling MS to send the 
extended_address information. For a status call to the PABX or PSTN the extended_address information shall be BCD 
digits. The Proxy Flag information element in the C-AHOY PDU shall be copied from the Proxy Flag information 
element received from the MS C_RAND PDU. If the TSCC does not successfully receive the UDT from the MS, the 
TSCC may repeat the C_AHOY, or transmit a C_NACKD to indicate failure of the call. 

For c) The TSCC shall then invoke the UDT procedure by sending a C_AHOY to the calling MS to send the 
supplementary data. The format of the supplementary data is specified in the UDT. If the TSCC does not successfully 
receive the UDT from the MS, the TSCC may repeat the C_AHOY, transmit a C_NACKD to indicate failure of the call 
or continue with the call setup and abandon the supplementary data. 

6.6.6.1 .1 .3 Acknowledgements sent by the TSCC to the calling MS (status) 

The TSCC may send acknowledgement PDUs following the random access Status service request to indicate the 
progress of the call, or terminate the call. If the TSCC sends a PDU to indicate the progress of a call it shall start a 
waiting timer TNP_Timer. (The calling party MS maintains a similar timer). 

a) Progress PDUs may be: 

1) C_WACKD: Intermediate acknowledgement. More PDUs to follow. 

2) C_QACKD: Called MS engaged in another call. 

3) C_QACKD: Call is queued because the resource is in use at the moment. 

b) Termination PDUs are selected from an appropriate Reason information element in a C_NACKD PDU 
(see clause 7.2.8): 

1) C_NACKD. 

6.6.6.1 .1 .4 Delivery of the status to the called party 

The TSCC delivers the status to the called MS by transmitting a C_AHOY PDU containing the Status information 
element. The status message may have originated from another MS, a gateway or the TSCC. For a status delivery 
service to an individual MS ID, the C_AHOY PDU demands a response from the called MS. If the response is 
C_ACKU or C_NACKU, the TSCC shall send an equivalent acknowledgement to the calling party (mirrored_reason). 
If no response is received the TSCC may repeat the C_AHO Y or abandon the service and indicate the failure to the 
called party by transmitting a C_NACKD. If the status delivery service is directed to a talkgroup, no acknowledgement 
shall be transmitted by the called talkgroup, nor is an acknowledgement expected by the TSCC. For reliability the 
C_AHOY may be repeated. 

6.6.6.1.1.5 CallTimeOut 

The TSCC shall maintain a timeout defining the maximum time it shall store a status message request waiting for the 
called MS or TSCC resource to become free. 
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6.6.6.1.2 



Status Service Delivery Procedures for IVIS 



A MS requests a status message call service to another individual MS or a talkgroup using a single part service request 
or gateway using a multi-part service request. For calls to an extended_address the sending of the extended_address is 
by a UDT transfer. 

A MS requests a status service by sending a C_RAND random access request complying with the random access 
procedures in clause 6.2. The information elements in the random access request are passed to the CC layer - set 
appropriately as prescribed in table 6.45. 

Table 6.45: C_RAND information elements for a Status Message Service 



Information 
Element (I.E) 


I.E 
Length 


length 


Alias 


Value 


Remark 


Service Options 


1 




IG 


O2 


The target address is an MS individual ID 


I2 


The target address is a talkgroup 


1 




Supplementary 
_user Data 


O2 


No supplementary_user data transfer 
requested 




I2 


Supplementary_user data is requested for 
this call 


5 




STATUS(5) 


value 


Most significant 5 bits of the STATUS 


Proxy Flag 


1 




PROXY 


02 


Number of Extended BCD digits for 
addressing through a gateway = 1 to 20 


I2 


Number of Extended BCD digits for 
addressing through a gateway = 21 to 44 


Appended_Supplem 
entary_Data 


2 




SUPED_VAL 


Value 


Number of appended UDTs required to 
transport supplementary data 




2 




STATUS(2) 


value 


Least significant 2 bits of the STATUS 


Service_Kind 


4 




IND_ST_SRV 


OIII2 


Status Transport Service 


Target_address or 
Gateway 


24 






Value 


Target Address (see note 2) 


Source address 


24 






Value 


Individual Address of the requesting MS 


NOTE 1 : Privacy is not defined in the present document. 

NOTE 2: Target_Address represents an Individual address or gateway or a talkgroup if \G=^2• 



6.6.6.1.2.1 



6.6.6.1.2.1.1 



Status message service to an individual MS or gateway 
Initiating the Status Message service to the MS or gateway 



For a status message service request to an individual MS , the destination address is completely expressed by the Target 
Address information element in the C_RAND random access PDU. IG=02. The Service_Kind specifies the Status 
Message call service. For calls to a gateway addresses the Target_address or Gateway information element in the 
C_RAND is set to the gateway address. 

The MS shall attempt access until it receives a valid response, or the service is cancelled by the user, or the attempt fails 
by sending the maximum number of random access PDUs or the random access timer expires. 

6.6.6.1 .2.1 .2 Response to a random access status message service request 

The calling MS shall accept the following PDUs a valid response to the status service random access request: 

a) An acknowledgement PDU C_NACKD, C_QACKD, C_WACKD. 

b) A UDT Head + appended block(s) (short data call is diverted). 

c) A C_AHOY PDU to the called MS containing the status. 
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d) A C_AHOY PDU from AUTHI (MS authentication check). 

e) A C_AHOY PDU instructing the calHng MS to transport supplementary data using the UDT mechanism. 

f) For a call to an extended_address, A C_AHOY PDU from PABXI,PSTNI,LINEI,DISPATI,IPI instructing the 
calling party to send its extended_address using the UDT mechanism. 

NOTE: d), e) and f) may be performed in any order. 

6.6.6.1 .2.1 .3 Acknowledgements received by the calling MS 

When the C_RAND PDU has been transmitted by the calling party, an initial response may be received by the calling 
party as specified in clause 6.6.6.1.1.3. 

At any time further PDUs may be sent to the calling party as follows: 

a) A C_NACKD at any time to indicate the call has failed. The Reason information element shall be set to 
indicate the reason for the call failure. If the C_NACKD sent to the calling MS is the result of a C_NACK 
from the called MS, a mirrored_reason code shall be sent to the calling MS. 

b) A C_WACKD if more signalHng will follow. 

c) After the status message has been successfully transported, a C_ACKD PDU (mirrored_reason). 
If a C_NACKD is received, the calling MS shall abandon the status message call and return to the idle state. 
If a C_WACKD is received the MS shall start/restart the TNP_Timer and wait for further signalling. 

Any acknowledgement or valid C_AHOY PDU received shall restart the TNP_timer. 

6.6.6.1 .2.1 .4 Timeout waiting for further signalling 

A MS waiting for further signalling shall abandon the status message service and return to the idle state if the 
TNP_Timer expires. 

6.6.6.1 .2.1 .5 MS receiving a status message 

If a MS receives a C_AHOY message with the Target Address matching its individual address, it shall respond with an 
appropriate acknowledgement. The Service_Options information element contains the status message. 

6.6.6.1 .2.2 Status Message Service to a talkgroup 

6.6.6.1 .2.2.1 Initiating the Status Message service to the talkgroup 

For a status message service request to a talkgroup, the destination address is completely expressed by the Target 
Address information element in the C_RAND random access PDU. IG=l2. The Service_Kind specifies the Status 
Message call service. 

The MS shall attempt access until it receives a valid response, or the service is cancelled by the user, or the attempt fails 
by sending the maximum number of random access PDUs or the random access timer expires. 

6.6.6.1 .2.2.2 Response to a random access talkgroup status message service request 
The calling MS shall accept the following PDUs a valid response to the status service random access request: 

a) An acknowledgement PDU C_NACKD, C_QACKD, C_WACKD. 

b) A UDT Head + appended block(s) (short data call is diverted). 
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c) A C_AHOY PDU to the called talkgroup containing the status. 

d) A C_AHOY PDU from AUTHI (MS authentication check). 

e) A C_AHOY PDU from SUPPLI instructing the calling MS to transport supplementary data using the UDT 
mechanism. 

NOTE: d) and e) may be performed in any order. 



6.6.6.1.2.2.3 



Acknowledgements received by the calling MS 



When the C_RAND PDU has been transmitted by the calling party, an initial response may be received by the calling 
party as specified in clause 6.6.6.1.1.3. 

At any time further PDUs may be sent to the calling party as follows: 

a) A C_WACKD if more signalHng will follow. 

If a C_WACKD is received the MS shall start/restart the TNP_Timer and wait for further signalling. 

Any acknowledgement or valid C_AHOY PDU received shall restart the TNP_timer. 



6.6.6.1.2.2.4 



Timeout waiting for further signalling 



A MS waiting for further signalling shall abandon the status message service and return to the idle state if the 
TNP_Timer expires. 



6.6.6.1.2.2.5 



Talkgroup receiving a status message 



If a talkgroup receives a C_AHOY message with the Target Address matching its talkgroup address, it shall store the 
status value but will not send any acknowledgement. 

6.6.7 Call Diversion 



6.6.7.1 



Call Diversion Service 



The call diversion service supports a self initiated diversion - that is a MS may request that all future services be 
redirected to an alternative destination. Requests are applicable to: 

a) Voice call service. 

b) Packet Data service. 

c) Short data message delivery service. 

d) Status message service. 

Applicable Services may be redirected to another MS, a talkgroup, or an extended_address through a gateway. 

The "Set Diversion" call diversion service uses a multi-part call set-up and the diversion address is sent by the caller 
using the UDT mechanism. This is recognized by the DIVONOFF information element in the diversion service request 
set to "Set Call Diversion" (=12). 
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Figure 6.49: Example of a Call Diversion Call 
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a) MS (A) defines the number of appended UDTs needed to transport the diverted address to the TSCC. In this 
example, one appended UDT is required. 

b) "A" is the random access C_RAND PDU. The Service_Kind set to 'Call Diversion Service' and the 
Appended_Short_Data PDU to the number of UDT appended blocks to transport the diverted address. 

c) "B" is a C_AHOY PDU from DIVERTI that requests MS(A) to transport the diversion address using the UDT 
mechanism. 

d) "C" is the inbound phase consisting of a Multi-block UDT header + appended data transporting the diverted 
address to the TSCC. 

e) "D" is the acknowledgement from the TSSC. 

If the Service_Options information element DIVONOFF in the call diversion Service request is set to "Clear Diversion" 
then a single part call set-up with the Target Address set to DIVERTI. 



6.6.7.1.1 



TSCC Procedures for the Call Diversion Service 



A MS initiates a Set Call Diversion Service by random access addressed to the gateway identifier appropriate to the 
diverted destination - individual MS address, talkgroup, PTSN, PABX or IP. The set call diversion service uses the 
multi-part call set-up. When the TSCC responds to the random access request it shall start timer (TNP_Timer). This 
timer shall be refreshed if the TSCC sends further call progress PDUs to the calling party. 

A MS initiates a Clear Call Diversion Service by random access addressed to the gateway identifier DIVERTI. The 
clear call diversion service uses the single-part call set-up. When the TSCC responds to the random access request it 
shall start timer (TNP_Timer). This timer shall be refreshed if the TSCC sends further call progress PDUs to the calling 
party. 



6.6.7.1.1.1 



TSCC Response to a multi-part Set Call Diversion Service call setup 



To set call diversion service, the MS generates a random access diversion service request with the C_RAND 
information elements set as table 6.47 and the DIVONOFF information element set to Set Call Diversion (=12). 

The PDUs that shall represent a valid response to the set call diversion service multi-part random access request are: 

a) An acknowledgement PDU C_NACKD, C_WACKD(reason=Wait). 

b) A C_AHOY PDU from DIVERTI for the calling MS to send the diverted address using the UDT mechanism. 

c) A C_AHOY PDU from AUTHI (MS authentication check). 

For b) the TSCC shall invoke the UDT procedure by sending a C_AHOY to the calling MS to send the diverted address 
information. For a call diversion to the PABX or PSTN the diverted address information shall be BCD digits. The Proxy 
Flag information element in the C-AHOY PDU shall be copied from the Proxy Flag information element received from 
the MS C_RAND PDU. If the TSCC does not successfully receive the UDT from the MS, the TSCC may repeat the 
C_AHOY, or transmit a C_NACKD to indicate failure of the call. 

The gateway information elements for C_AHOY PDUs to upload the diverted address is prescribed in table 6.46. 
Table 6.46: C AHOY information elements for the Set Call Diversion Service 



Action 


Gateway 
Address 


Remark 


Send the individual IVIS Address 


MS ID 


The calling party shall send the MS Individual diversion address 


Send the Talkgroup Address 


GPI 


The calling party shall send the MS talkgroup diversion address 


Send PSTN digits 


PSTNI 


The calling party shall send BCD dialled digits 


Send PABX digits 


PABXI 


The calling party shall send BCD dialled digits 


Send LINE digits 


LINEI 


The calling party shall send BCD dialled digits 


Send Dispatcher digits 


DISPATI 


The calling party shall send BCD dialled digits 


Send IP address 


IPI 


The calling party shall send the IPV4 or IPV6 address 
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6.6.7.1.1.2 



TSCC Response to a single-part Clear Call Diversion Service set-up 



For the clear call diversion service, the MS generates a random access diversion service request with the C_RAND 
information elements set as table 6.48 and the DIVONOFF information element set to Clear Call Diversion (=02). 

The PDUs that shall represent a valid response to the clear call diversion service multi-part random access request are: 

a) An acknowledgement PDU C_NACKD indicating that the service request has not succeeded. 

b) C_WACKD(reason=Wait) further signalling to follow. 

c) An acknowledgement C_ACKD indicating that the service request has succeeded. 

6.6.7.1 .2 MS Procedures for the Call Diversion Service 

A MS requests the call diversion service using a random access service request. 

If the MS wishes to divert its calls the DIVONOFF information element in the Service_Options is set to "Set Diversion 
(=12)". A multi-part service request is invoked. The information elements in the random access request are passed to the 
CC layer - set appropriately as prescribed in table 6.47. 

If the MS wishes to cancel a previously set diversion, the same random access request is. 

Table 6.47: C RAND information elements for a Call Diversion Service 



Information 
Element (I.E) 


I.E 
Length 


length 


Alias 


Value 


Remark 


Service_Options 


7 


1 


EMERG 


Not applicable - O2 


1 




02 


Privacy (see note) 


1 


DIVONOFF 


02 


Clear Call Diversion 


I2 


Set Call Diversion 


1 


DIV VD 


Active 1 2 
Inactive O2 


Divert Voice Calls 


1 


DIV PD 


Divert Packet Data Calls 


1 


DIV SD 


Divert Short Data Calls 


1 


DIV S 


Divert Status Calls 


Proxy Flag 


1 




PROXY 


O2 


Number of Extended BCD digits for 
addressing through a gateway = 1 to 20 
or IPV4 


I2 


Number of Extended BCD digits for 
addressing through a gateway = 21 to 44 
or IPV6 


Appended_Supplem 
entary Data 


2 




SUPED_VAL 


OO2 


Not Defined for the call diversion Service 


Appended_Short_ 
Data 


2 




SDATA_VAL 


OO2 


Not Defined for the call diversion Service 


Service_Kind 


4 




DIV_SRV 


IOOO2 


Call Diversion Service 


Target_address or 
Gateway 


24 






value 


Gateway Identifier - MS ID, GPI, PSTNI, 
PABXI, IPI 


Source address 


24 






Value 


Individual Address of the requesting MS 


NOTE: Privacy is not defined in the present document. 



If DIV0N0FF=l2, the alias DIV_VD, DIV_PD, DIV_SD and DIV_S that are set to Active (I2): define which services 
shall be diverted for this call diversion service request. 

If DIVONOFF=02, the aUas DIV_VD, DIV_PD, DIV_SD and DIV_S that are set to Active (I2): define which services 
shall have the call diversion cancelled. 



ETSI 



134 



ETSI TS 102 361-4 V1.3.1 (2010-06) 



Table 6.48: Information element definitions for the Call Diversion Service 



Diversion Address 


Target Address or Gateway 


Proxy Flag 


Individual IVIS Address 


MSI 


02 


Talkgroup Address 


GPI 


02 


PSTN Address (1 to 20 dialled digits) 


PSTNI 


02 


PSTN Address (21 to 44 dialled digits) 


PSTNI 


I2 


PABX Address(1 to 20 dialled digits) 


PABXI 


02 


PABX Address (21 to 44 dialled digits) 


PABXI 


I2 


Ipv4 Address 


IPI 


02 


Ipv6 Address 


IPI 


I2 



6.6.7.1.2.1 



MS Sends the Diversion Address 



After the MS has made a call diversion service request, the TSCC sends a C_AHOY PDU to which the MS shall 
respond with a UDT Header + Appended block(s) using the UDT mechanism. The UDT header shall contain the 
destination address type (MS, PSTN, etc.) and the appended block(s) shall contain the diversion address. 

The information elements for the UDT inbound Header are specified in table 6.49. 

Table 6.49: Information element Definitions for the Call Diversion UDT Header 



Diversion Address 


UDT Inbound Channel Header Information Element 




UDT Format 


Appended Blocks 


Target 

Address or 

Gateway 


Source 

Address or 

Gateway 


Individual IVIS 


Address -0001 2 


OO2 


MSI 


MS Address 


Talkgroup 


Address -0001 2 


OO2 


GPI 


MS Address 


PSTN destination 


BCD- 001 O2 


1 to 20 digits - OO2 
21 to 44 digits -01 2 


PSTNI 


MS Address 


PABX destination 


BCD- 001 O2 


1 to 20 digits - OO2 
21 to 44 digits -01 2 


PABXI 


MS Address 


IP destination 


IP-OIIO2 


IPV4-OO2 
IPV6-OI2 


IPI 


MS Address 


NOTE: Supplementary_Flag = O2, UDT_Response = O2, Service_Kind = IOOO2. 



6.6.7.2 



Diverting Calls 



An MS makes a service access request by random access. If the destination address selected is an individual MS address 
and the system determines that calls to this address are diverted, the TSCC shall acknowledge the random access 
request with a UDT header -\- appended with the diverted address. 
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Figure 6.50: TSCC provides diverted address to MS 
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The UDT Header sets the following information elements: 

• DIV = I2. 

• Supplementary Flag = l2- 

• UDT Response - I2. 

• Target_address or Gateway - Address of the calling MS. 

Where the appended UDT block conveys an address the ADDRESS 1 information element shall convey the diverted 
address. 

Table 6.50 indicates the UDT Header information elements for the services and diversion addresses. 

Table 6.50: Information elements for UDT Header to convey diverted address 



Service 
Request 


Divert to 


UDT Header information elements 






UDT 
Format 


Appended Blocks 


Service_Kind 


Source Address 


Private Voice 


MS 
address 


Address 
0001 2 


OO2 


OOOO2 


MSI 


Talkgroup 


Address 
0001 2 


OO2 


TGI 


PTSN 


BCD 
001 O2 


1 to 20 digits - OO2 
21 to 44 digits -01 2 


PSTNI 


PABX 


BCD 
001 O2 


1 to 20 digits - OO2 
21 to 44 digits -01 2 


PABXI 


Private 
Packet Data 


MS 
address 


Address 
0001 2 


OO2 


001 O2 


MSI 


Talkgroup 


Address 
0001 2 


OO2 


TGI 


PSTN 


BCD 
001 O2 


1 to 20 digits - OO2 
21 to 44 digits -01 2 


PSTNI 


PABX 


BCD 
001 O2 


1 to 20 digits - OO2 
21 to 44 digits -01 2 


PABXI 


IP 


IP 
OIIO2 


IPV4 - OO2 
IPV6-OI2 


IPI 


Short Data 


MS 
address 


Address 
0001 2 


OO2 


OIOO2 


MSI 


Talkgroup 


Address 
0001 2 


OO2 


TGI 


PTSN 


BCD 
001 O2 


1 to 20 digits - OO2 
21 to 44 digits -01 2 


PSTNI 


PABX 


BCD 
001 O2 


1 to 20 digits - OO2 
21 to 44 digits -01 2 


PABXI 


IP 


IP 
OIIO2 


IPV4 - OO2 
IPV6-OI2 


IPI 


Status 


MS 
address 


Address 
0001 2 


OO2 


OIII2 


MSI 


PTSN 


BCD 
001 O2 


1 to 20 digits - OO2 
21 to 44 digits -01 2 


PSTNI 


PABX 


BCD 
001 O2 


1 to 20 digits - OO2 
21 to 44 digits -01 2 


PABXI 


IP 


IP 
OIIO2 


IPV4 - OO2 
IPV6-OI2 


IPI 
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6.7 System Management Procedures 
6.7.1 Network System Announcements 

Announcement PDUs are transmitted by a TSCC and contain information about system parameters for either this TS or 
another TS. Announcement PDUs may be transmitted frequently and therefore contain the System Identity Code for 
TSCC identification. 

Announcement Type (BCASTTYP) specifies which system parameters are being broadcast: 

a) AnnounceAVithdraw TSCC. 

b) Specify Call Timer Parameters. 

c) Vote Now Advice. 

d) Announce Local Time. 

e) Mass registration. 

f) Announce a logical/physical frequency plan relationship. 

g) Adjacent site information. 

6.7.1 .1 Announce/Withdraw TSCC 

This announcement adds and/or withdraws a TSCC radio channel that is active in a wide area system. The 
announcement PDU carries up to two Logical Physical Channel Number Elements. If only one Logical Channel 
Number is announced, the remaining element shall be set to CHNULL. MSs shall add/withdraw the logical channel(s) 
to/from their Short Hunt list of physical channels to hunt (see annex D). 

6.7.1 .2 Specify Call Timer parameters 

This PDU specifies the call timer parameters for: 

a) Calls between MS and MS or MS and a talkgroup. 

b) Calls between a Line Connected Service and an MS or Talkgroup. 

c) Calls that use the Packet Data Service. 

d) Emergency Calls. 

6.7.1 .3 Vote now advice 

The Network System Announcements (Vote Now Advice) PDU gives an opportunity to idle MSs to assess the signal 
quality of another TSCC specified by the announcement (see clause 7.2.19.3). The PDU provides a sub-set of the 
system identity code (C_SYSCode), and the logical channel number (CH_VOTE) of the TSCC the MS is being invited 
to assess for improved signal quality. 

While MSs are assessing the signal quality of an adjacent TSCC, they are not able to receive call set-up PDUs. The 
TSCC shall therefore not use the next VOTE_BLK TDMA frames (see clause A.2) to signal to MSs that are likely to be 
assessing the signal strength of the adjacent site. Only the following PDUs may be transmitted on the TSCC in the 
VOTE_BLK slots following transmission of a Vote Now Advice announcement: 

a) An Aloha PDU with MS Address = NULL and Mask=24. 

b) A C_WACKD. 
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6.7.1 .4 Announce Local Time 



This PDU transmits the local date and time to MSs. The PDU permits the date and UTC_OFFSET to be omitted from 
the announcement. 

If UTC_OFFSET <> ' 1 1 1 1 1' then 

UTC time = (B_HOURS + UTC_OFFSET + UTC_OFFSET_FRACTION) MOD 24 

6.7.1 .5 Mass Registration 

This PDU invites all MS or a sub-set of MS to register over a short or extended time period. The description and 
procedures are specified in the registration clauses 6.4.5. 

6.7.1 .6 Announce a logical physical channel relationship 

This PDU announces a logical to physical channel relationship. The PDU defines the physical transmitter and receiver 
frequencies to be assigned to a logical channel. 



7 PDU description 

This clause describes the PDUs which apply to the DMR layer 3, the Tier III trunking services and facilities protocol. 

The following clauses contain descriptions of the PDUs and the information elements contained within them. The 
structure of the PDU definition represented by the tables is as follows: 

• the information element column gives the name of the contained element(s); 

• the element length column defines the length of the element in bits; 

• the Alias used in the description of the procedures; 

• the remarks column contains other information on the information element. 
The elements shall be transmitted in the order specified by TS 102 361-1 [5]. 



7.1 Layer 3 PDUs 



Due to the nature of DMR, with close interaction between layers 2 and 3, and with a high degree of information about 
the state of the channel being needed, the layer 3 PDUs detailed in the following clauses may include two element 
types: 

• Message dependent elements: 

These elements are visible to layer 2 and may be used by any MS (that is able to decode them), 
irrespective of addressing. These elements depend on the message type element. Some are generated by 
layer 2 when it constructs the complete message whereas others are generated by layer 3. 

• Facility elements: 

These are "true" layer 3 elements. They are only processed by the MSs to which they are addressed. 
Where both types exist in the PDU they are illustrated separately. 
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7.1 .1 Control Signalling Block (CSBK/MBC/UDT) PDUs 

CSBK/MBC and UDT PDUs form a core part of the Tier III protocol. The control signalling PDUs are classified into 
their core functionality. 

The Call Control Layer 3 requires three Data Type bursts (see TS 102 361-1 [5], clause 6.2). These are listed in: 

• table 7. 1 for TSCC outbound PDUs; 

• table 7.2 for TSCC inbound PDUs; 

• table 7.3 for Payload channel outbound PDUs; and 

• table 7.4 for Payload inbound PDUs. 

Table 7.1 : TSCC Outbound channel PDU Structure 



Class 


Alias 


Function 


Opcode 


Data Type 


Value 


Broadcast 


PV_GRANT 


Private Voice Channel Grant 
(logical) 


1 1 OOOO2 


CSBK 


OOII2 


Private Voice Channel Grant 
(absolute) 


MBC Header 


OIOO2 


Broadcast 


TV_GRANT 


Talkgroup Voice Channel 
Grant (logical) 


11 0001 2 


CSBK 


OOII2 


Talkgroup Voice Channel 
Grant (absolute) 


MBC Header 


OIOO2 


Broadcast 


BTV_GRANT 


Broadcast Talkgroup Voice 
Channel Grant (logical) 


11 001 O2 


CSBK 


OOII2 


Broadcast Talkgroup Voice 
Channel Grant (absolute) 


MBC Header 


OIOO2 


Broadcast 


PD_GRANT 


Private Data Channel Grant 
(logical) 


11 001 12 


CSBK 


OOII2 


Private Data Channel Grant 
(absolute) 


MBC Header 


OIOO2 


Broadcast 


TD_GRANT 


Talkgroup Data Channel 
Grant (logical) 


11 01002 


CSBK 


OOII2 


Talkgroup Data Channel 
Grant (absolute) 


MBC Header 


OIOO2 


Broadcast 


CG_AP 


Channel Grant Appended 
MBC 


Value 

from 

header 


MBC 
Continuation 


OIOI2 


Broadcast 


C_MOVE 


Move TSCC (logical) 


11 IOOO2 


CSBK 


OOII2 


Move TSCC (absolute) 


MBC Header 


OIOO2 


Broadcast 


MV_AP 


Move Appended MBC 


11 IOOO2 


MBC 
Continuation 


OIOI2 


Broadcast 


C_ALOHA 


Aloha 


01 IOOI2 


CSBK 


OOII2 


Broadcast 
(C_BCAST) 


Ann WD 
TSCC 


Announce/Withdraw TSCC 
(logical) 


IOIOOO2 


CSBK 


OOII2 


Ann WD 
TSCC 


Announce/Withdraw TSCC 
(absolute) 


MBC Header 


OIOO2 


CallTimer 
Parms 


Specify Call Timer 
Parameters 


CSBK 


OOII2 


Vote_Now 


Vote Now Advice 


CSBK 


OOII2 


Local_Time 


Broadcast Local Time 


CSBK 


OOII2 


MassReg 


Broadcast Mass Registration 


CSBK 


OOII2 


Chan_Freq 


Announce a logical channel / 
frequency relationship 


CSBK 


OOII2 
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Class 


Alias 


Function 


Opcode 


Data Type 


Value 


Broadcast 


BC_AP 


Broadcast Appended IVIBC 


IOIOOO2 


MBC 
Continuation 


OIOI2 


Ahoy 
(AHOY) 


AHOY 


Stun/Unstun 
Poll MS 
MS Check 


01 110O2 


CSBK 


OOII2 


Acknowledg 
ements 


C ACKD 
C NACKD 
C QACKD 
C WACKD 


Positive Acknowledgement 
Negative Acknowledgement 
The call is queued 
Wait - further PDUs follow 


IOOOOO2 


CSBK 


OOII2 


Unified 

Data 

Transport 


C_UDTHD 


Unified Data Transport 
Header 


N/A 


Data Header 
(UDT) 


011 O2 


Unified 

Data 

Transport 


UDT 


Unified Data Transport 
Appended Data 


N/A 


Unconfirmed 

Data 
Continuation 


OIII2 



Table 7.2: TSCC Inbound Channel PDU Structure 



Class 


Alias 


Function 


Opcode 


Data Type 


Value 


Random 
Access 


C_RAND 


Random Access Requests 


01 IIII2 


CSBK 


OOII2 


Ackvitation 


C_ACKVIT 


Ackvitation 


01 IIIO2 


CSBK 


OOII2 


Acknowledg 
ement 


C ACKU 
C NACKU 


Acknowledgement 


10 0001 2 


CSBK 


OOII2 


Unified 

Data 

Transport 


C_UDTHD 


Unified Data Transport 
Header 


N/A 


Data Header 
(UDT) 


OIIO2 


Unified 

Data 

Transport 


UDT 


Unified Data Transport 
Appended Data 


N/A 


Unconfirmed 

Data 
Continuation 


OIII2 



Table 7.3: Payload Outbound channel PDU Structure 



Class 


Alias 


Function 


Opcode 


Data Type 


Value 


Broadcast 


P_GRANT 


Channel Grant (logical) 


Value 
from 
Chan 
Grant 


CSBK 


OOII2 


Private Voice Channel Grant 
(absolute) 


MBC Header 


OIOO2 


Broadcast 
(Clear) 


P_CLEAR 


Clear the call from the 
payload channel. MS return 
to the TSCC 


IOIIIO2 


CSBK 


OOII2 


Broadcast 
(Protect) 


P_PROTECT 


Broadcast Talkgroup Voice 
Channel Grant (logical) 


IOIIII2 


CSBK 


OOII2 


Ahoy 


P_AHOY 


MS Check 


01 IIOO2 


CSBK 


OOII2 


Acknowledg 
ements 


P ACKD 
P NACKD 


Positive Acknowledgement 
Negative Acknowledgement 


IOOOOO2 


CSBK 


OOII2 



Table 7.4: Payload Inbound Channel PDU Structure 



Class 


Alias 


Function 


Opcode 


Data Type 


Value 


Random 
Access 


P_RAND 


Random Access Include 
Request 


01 IIII2 


CSBK 


OOII2 


Acknowledg 
ement 


P_ACKU 


Acknowledgement 


10 0001 2 


CSBK 


OOII2 


Maintenance 


P_MAINT 


Call Maintenance 


1010102 


CSBK 


OOII2 
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Figure 7.1 illustrates the hierarchy of the TSCC outbound channel PDU structure. 



SLOT 



Broadcasts 
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Acknowledgements 



Unified Data 
Transport 
Download 




Figure 7.1 : Hierarchy for tlie TSCC outbound channel PDUs 

The top level of the structure describes a basic behaviour illustrated in table 7.5. 

Table 7.5: Top Level Structure for TSCC Outbound channel CSBKs / MBCs /UDTs 



Broadcasts 


PDUs sent by a TSCC to manage the channel access, transfer MS or talkgroups 
to payload channels and announce information about the TS 


Ahoys 


To demand a response from MS and also to acknowledge random access 
channel access 


Acknowledgments 


To provide responses to Ahoys and UDT 


UDT 


To transport information between TSCC and MS 
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A similar structure exists for the inbound channel illustrated in figure 7.2. 
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Figure 7.2: Hierarchy for tlie MS inbound channel PDUs to a TSCC 

The basic PDU behaviour for the inbound channel is illustrated in table 7.6. 

Table 7.6: Top level structure for MS on the TSCC inbound 



Random Access 


Used for channel access and request Tier III services 


Acknowledgments 


To provide responses to Ahoys and UDT 


UDT 


To transport information between MS and TSCC 



A pay load channel outbound channel is illustrated in figure 7.3. 
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Figure 7.3: Hierarchy for Outbound channel CSBKs/MBCs on a payload channel 

The top level of the structure describes a basic behaviour illustrated in table 7.7. 

Table 7.7: Top level structure for MS inbound channel CSBKs on a control channel 



Broadcasts 


PDUs sent by TS to manage the payload channel - swap MS to a new channel, 
clear the participants from the channel and protect the channel during breaks in 
MS transmission items 


Ahoys 


For polling MS - demands a response 


Acknowledgments 


To provide responses to Ahoys and UDT 
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The payload inbound channel. 
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Figure 7.4: Hierarchy for the MS inbound channel PDUs to a payload channel 

The basic PDU behaviour for the inbound channel is illustrated in table 7.8. 

Table 7.8: Top level structure for MS on the payload channel inbound channel 



Random Access 


Used to request an include call service 


Acknowledgments 


To provide responses to Ahoys and UDT 


Maintenance 


To provide call maintenance PDUs 



7.1.1.1 



TSCC Outbound channel CSBK/MBC/UDT 



7.1.1.1.1 



7.1.1.1.1.1 



Channel Grant CSBK/MBC PDU 



Private Voice Channel Grant (PV_GRANT) CSBK/MBC PDU 



Octet and 1 of the Private Voice Channel Grant CSBK PDU conforms to the LC format structure as defined in 
figure 7.1 in TS 102 361-1 [5] of the standard with the CSBKO replacing the FLCO. Octets 2 to 9 contain the Private 
Voice Channel Grant specific information illustrated in table 7.9. The Private Voice Channel Grant is transmitted by the 
TS and does not solicit a response. The Private Voice Channel Grant PDU is transmitted on the TSCC or a payload 
channel either as a single block CSBK or a Multi Block Control (MBC). For the Physical Channel Number Information 
Element: 

a) If the value = 0000 0000 OOOO2 the Physical Channel number is invalid. 

b) If the value = 0000 0000 0001 2 to 1 1 1 1 1 1 1 1 1 1 IO2, the Physical Channel number represent a logical channel 
number for the physical transmitter and receiver frequency. The Private Voice Channel Grant PDU is 
transmitted on the TSCC as a single block CSBK. 

c) If the value = 1111 1111 1111 2, the Physical Channel number defines a multi -block MBC where the absolute 
transmitter and receiver frequency is defined in a second block concatenated to this block (defined in 
clause 7.1.1.1.2). 
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Table 7.9: Private Voice Channel Grant PDU content 



Information element 


Length 


Remark 


Message dependent elements 


Last block (LB) 


1 


This bit shall be set to 1 2 for a single block CSBK or O2 if this is a 
MBC header 


Protect Flag (PF) 


1 




Feature elements 


CSBK Opcode (CSBKO) 


6 


Shall be set to 1 1 OOOO2 


Feature set ID (FID) 


8 


Shall be set to 0000 OOOO2 


Logical Physical Channel 
Number 


12 


Payload Channel for the Call or an indicator that the absolute Tx 
and Rx frequency is specified in an appended CSBK block 


Logical Channel Number 


1 


O2 - TDMA channel 1 
I2-TDMA channel 2 


OVCM 


1 


O2 - not OVCM call 
I2- OVCM Call 


Emergency 


1 


O2 - not an emergency call 
I2- emergency call 


Offset 


1 


O2 - Payload Channel uses aligned timing 
I2 - Payload Channel uses offset timing 


Target Address 


24 


Called party Individual MS Address or Gateway 


Source Address 


24 


Calling Party or Gateway 



7.1.1.1.1.2 



Talkgroup Voice Channel Grant (TV_GRANT) CSBK/MBO PDU 



Octet and 1 of the Talkgroup Voice Channel Grant CSBK PDU conforms to the LC format structure as defined in 
figure 7.1 in TS 102 361-1 [5] of the standard with the CSBKO replacing the FLCO. Octets 2 to 9 contain the 
Talkgroup Voice Channel Grant specific information illustrated in table 7.10. The Talkgroup Voice Channel Grant is 
transmitted by the TS. The Talkgroup Voice Channel Grant is transmitted by the TS and does not solicit a response. The 
Talkgroup Voice Channel Grant PDU is transmitted on the TSCC or a payload channel either as a single block CSBK 
or a Multi Block Control (MBC). For the Physical Channel Number Information Element: 

a) If the value = 0000 0000 OOOO2 the Physical Channel number is invahd. 

b) If the value = 0000 0000 000 1 2 to 1 1 1 1 1 1 1 1 1 1 IO2, the Physical Channel number represent a logical channel 
number for the physical transmitter and receiver frequency. The Talkgroup Voice Channel Grant PDU is 
transmitted on the TSCC as a single block CSBK. 
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c) If the value = 1 1 1 1 1 1 1 1 1 1 1 12, the Physical Channel number defines a Multi Block Control (MBC) where the 

absolute transmitter and receiver frequency is defined in a second block concatenated to this block (defined in 
clause 7.1.1.1.2). 
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Figure 7.6 
Table 7.10: Talkgroup Voice Channel Grant PDU content 



Information element 


Length 


Remark 


Message dependent elements 


Last block (LB) 


1 


This bit shall be set to 1 2 for a single block CSBK or O2 if this is a 
MBC header 


Protect Flag (PF) 


1 




Feature elements 


CSBK Opcode (CSBKO) 


6 


Shall be set to 11 0001 2 


Feature set ID (FID) 


8 


Shall be set to 0000 OOOO2 


Logical Physical Channel 
Number 


12 


Payload Channel for the Call or an indicator that the absolute Tx 
and Rx frequency is specified in an appended CSBK block 


Logical Channel Number 


1 


O2 - TDMA channel 1 
I2-TDMA channel 2 


OVCM 


1 


O2 - not OVCM call 
I2- OVCM Call 


Emergency 


1 


O2 - not an emergency call 
I2- emergency call 


Offset 


1 


O2 - Payload Channel uses aligned timing 
I2 - Payload Channel uses offset timing 


Target Address 


24 


MS Talkgroup Address 


Source Address 


24 


Calling Party or Gateway 



If the Target Address is the All_Unit Address ID 15 (see TS 102 361-1 [5], annex A) then a MS shall interpret this PDU 
as a broadcast. 
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7.1.1.1.1.3 



Broadcast Talkgroup Voice Channel Grant (BTV_GRANT) CSBK/MBO PDU 



Octet and 1 of the Broadcast Talkgroup Voice Channel Grant CSBK PDU conforms to the LC format structure as 
defined in figure 7.1 in TS 102 361-1 [5] of the standard with the CSBKO replacing the FLCO. Octets 2 to 9 contain the 
Broadcast Talkgroup Voice Channel Grant specific information illustrated in table 7.11. The Broadcast Talkgroup 
Voice Channel Grant is transmitted by the TS and does not solicit a response. The Broadcast Talkgroup Voice Channel 
Grant PDU is transmitted on the TSCC or a payload channel either as a single block CSBK or a Multi Block Control 
(MBC). For the Physical Channel Number Information Element: 

a) If the value = 0000 0000 OOOO2 the Physical Channel number is invahd. 

b) If the value = 0000 0000 OOOI2 to 1 1 1 1 1 1 1 1 1 1 IO2, the Physical Channel number represent a logical channel 

number for the physical transmitter and receiver frequency. The Broadcast Talkgroup Voice Channel Grant is 
transmitted on the TSCC as a single block CSBK. 

c) If the value = 1 1 1 1 1 1 1 1 1 1 1 12, the Physical Channel number defines a Multi-Block Control (MBC) where the 

absolute transmitter and receiver frequency is defined in a second block concatenated to this block (defined in 
clause 7.1.1.1.2). 
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Figure 7.7 
Table 7.11 : Broadcast Talkgroup Voice Channel Grant PDU content 



Information element 


Length 


Remark 


Message dependent elements 


Last block (LB) 


1 


This bit shall be set to 1 2 for a single block CSBK or O2 if this is a 
MBC header 


Protect Flag (PF) 


1 




Feature elements 


CSBK Opcode (CSBKO) 


6 


Shall be set to IIOOIO2 


Feature set ID (FID) 


8 


Shall be set to 0000 OOOO2 


Logical Physical Channel 
Number 


12 


Payload Channel for the Call or an indicator that the absolute Tx 
and Rx frequency is specified in an appended CSBK block 


Logical Channel Number 


1 


O2 - TDMA channel 1 
I2-TDMA channel 2 
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Information element 


Length 


Remark 


OVCM 


1 


O2 - not OVCM call 
I2- OVCM Call 


Emergency_Flag 


1 


l2-if an emergency call 


Offset 


1 


O2 - Payload Channel uses aligned timing 
I2 - Payload Channel uses offset timing 


Destination Address 


24 


MS Talkgroup Address 


Source address 


24 


Calling Party or Gateway 



7.1.1.1.1.4 



Private Data Channel Grant (PD_GRANT) CSBK/MBO PDU 



Octet and 1 of the Private Data Channel Grant CSBK PDU conforms to the LC format structure as defined in 
figure 7.1 in TS 102 361-1 [5] of the standard with the CSBKO replacing the FLCO. Octets 2 to 9 contain the Private 
Channel Grant specific information illustrated in table 7.12. The Private Data Channel Grant is transmitted by the TS 
and does not solicit a response. The Private Data Channel Grant PDU is transmitted on the TSCC or a payload channel 
either as a single block CSBK or a Multi Block Control (MBC). For the Physical Channel Number Information 
Element: 

a) If the value = 0000 0000 OOOO2 the Physical Channel number is invalid. 

b) If the value = 0000 0000 OOOI2 to 1 1 1 1 1 1 1 1 1 1 IO2, the Physical Channel number represent a logical channel 
number for the physical transmitter and receiver frequency. The Private Data Channel Grant PDU is 
transmitted on the TSCC as a single block CSBK. 

c) If the value = 1 1 1 1 1 1 1 1 1 1 1 12, the Physical Channel number defines a Multi Block Control (MBC) where the 

absolute transmitter and receiver frequency is defined in a second block concatenated to this block (defined in 
clause 7.1.1.1.2). 
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Table 7.12: Private Data Channel Grant PDU content 



Information element Length Remark 


Message dependent elements 


Last block (LB) 


1 


This bit shall be set to 1 2 for a single block CSBK or O2 if this is a 
MBC header 


Protect Flag (PF) 


1 




Feature elements 


CSBK Opcode (CSBKO) 


6 


Shall be set to 11 0011 2 


Feature set ID (FID) 


8 


Shall be set to 0000 OOOO2 


Logical Physical Channel 
Number 


12 


Payload Channel for the Call or an indicator that the absolute Tx 
and Rx frequency is specified in an appended CSBK block 


Logical Channel Number 


1 


O2 - TDMA channel 1 
I2-TDMA channel 2 


Packet Mode 


1 


O2 - Payload Channel uses 2:1 mode 
I2 - Payload Channel uses 1 :1 mode 


Emergency 


1 


O2 - not an emergency call 
I2- emergency call 


Offset 


1 


O2 - Payload Channel uses aligned timing 
I2 - Payload Channel uses offset timing 


Destination Address 


24 


Called party Individual MS Address or Gateway 


Source address 


24 


Calling Party or Gateway 



7.1.1.1.1.5 



Talkgroup Data Channel Grant (TD_GRANT) CSBK/MBO PDU 



Octet and 1 of the Talkgroup Data Channel Grant CSBK PDU conforms to the LC format structure as defined in 
figure 7.1 in TS 102 361-1 [5] of the standard with the CSBKO replacing the FLCO. Octets 2 to 9 contain the 
Talkgroup Data Channel Grant specific information illustrated in table 7.13. The Talkgroup Data Channel Grant is 
transmitted by the TS and does not solicit a response. The Talkgroup Data Channel Grant PDU is transmitted on the 
TSCC or a payload channel either as a single block CSBK or a Multi Block Control (MBC). For the Physical Channel 
Number Information Element: 

a) If the value = 0000 0000 OOOO2 the Physical Channel number is invaUd. 

b) If the value = 0000 0000 0001 2 to 1 1 1 1 1 1 1 1 1 1 IO2, the Physical Channel number represent a logical channel 
number for the physical transmitter and receiver frequency. The Talkgroup Data Channel Grant PDU is 
transmitted on the TSCC as a single block CSBK. 

c) If the value = 1 1 1 1 1 1 1 1 1 1 1 12, the Physical Channel number defines a Multi Block Control (MBC) where the 

absolute transmitter and receiver frequency is defined in a second block concatenated to this block (defined in 
clause 7.1.1.1.2). 
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Figure 7.9 
Table 7.13: Talkgroup Data Channel Grant PDU content 



Information element Length Remark 


Message dependent elements 


Last block (LB) 


1 


This bit shall be set to 1 2 for a single block CSBK or O2 if this is a 
MBC header 


Protect Flag (PF) 


1 




Feature elements 


CSBK Opcode (CSBKO) 


6 


Shall be set to 11 OIOO2 


Feature set ID (FID) 


8 


Shall be set to 0000 OOOO2 


Logical Physical Channel 
Number 


12 


Payload Channel for the Call or an indicator that the absolute Tx 
and Rx frequency is specified in an appended CSBK block 


Logical Channel Number 


1 


O2 - TDMA channel 1 
I2-TDMA channel 2 


Packet Mode 


1 


O2 - Payload Channel uses 2:1 mode 
I2 - Payload Channel uses 1 :1 mode 


Emergency 


1 


O2 - not an emergency call I2 - emergency call 


Offset 


1 


O2 - Payload Channel uses aligned timing 
I2 - Payload Channel uses offset timing 


Destination Address 


24 


MS Talkgroup Address 


Source address 


24 


Calling Party or Gateway 



7.1.1.1.2 



Channel Grant Absolute Parameters (CG_AP) appended MBC PDU 



The second (continuation) block of the multi -block Channel Grant MBC conforms to the format specified in table 7.14. 
The CdefParms PDU is specified in clause 7.2.19.7 and the physical characteristics described in annex C. 
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Table 7.14: C_DEF appended Channel Grant MBC PDU content 



Information element Length Remark 


Message dependent elements 


Last block (LB) 


1 


This bit shall be set to ^2 because this PDU is appended to either a 
an applicable Channel Grant MBC Header 


Protect Flag (PF) 


1 




Feature elements 


CSBK Opcode (CSBKO) 


6 


Shall be set to the CSBKO of the first block of the multi-block 
CSBK 


Reserved 


4 


OOOO2 


Colour Code 


4 


Colour Code used for the destination physical channel 


Cdeftype 


4 


Meaning of CdefParms (see clause 7.2.19.7) 


Reserved 


2 


OO2 


CdefParms 


58 


information elements describing the logical / physical channel 
frequency relationship 



7.1.1.1.3 



Move TSCC (C_MOVE) CSBK/MBC PDU 



Octet and 1 of the Move TSCC CSBK PDU conforms to the LC format structure as defined in figure 7.1 in 
TS 102 361-1 [5] of the standard with the CSBKO replacing the FLCO. Octets 2 to 9 contain the Move TSCC specific 
information illustrated in table 7.15. The Move PDU is transmitted on the TSCC either as a single block CSBK or a 
Multi Block Control (MBC). For the Physical Channel Number Information Element: 

a) If the value = 0000 0000 OOOO2 the Physical Channel number is invahd. 

b) If the value = 0000 0000 0001 2 to 1 1 1 1 1111 1 1 IO2, the Physical Channel number represent a logical channel 

number for the physical transmitter and receiver frequency. The Move PDU is transmitted on the TSCC as a 
single block CSBK. 

c) If the value = 1 1 1 1 1 1 1 1 1 1 1 12, the Physical Channel number defines a Multi Block Control (MBC) where the 
absolute transmitter and receiver frequency is defined in a second block concatenated to this block (see 
clause 7.1.1.1.3.1). 
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Table 7.15: Move TSCC PDU content 



Information element Length 


Remark 


Message dependent elements | 


Last First block (LB) 


1 


This bit shall be set to 1 2 for a single block CSBK or O2 if this is a MBC 
header 


Protect Flag (PF) 


1 




Feature elements 


CSBK Opcode (CSBKO) 


6 


Shall be set to 11 IOOO2 


Feature set ID (FID) 


8 


Shall be set to 0000 OOOO2 


Reserved 


9 


0000 OOOO2 


Mask 


5 




Reserved 


5 




Reg 


1 


This bit is set if the TSCC demands MS register before becoming active 


Backoff 


4 


Backoff Number 


Reserved 


4 




Physical Channel Number 


12 


Payload Channel for the Call or an indicator that the absolute Tx & Rx 
frequency is specified in an appended CSBK block 


MS address 


24 


MS Individual Address 



7.1.1.1.3.1 



Move Absolute Parameters appended (MV_AP) MBC PDU 



The second block of the Multi Block Move MBC conforms to the format specified in table 7.16. The CdefParms PDU 
is specified in clause 7.2.19.7 and the physical characteristics described in annex C. 

Table 7.16: C_DEF appended Move MBC PDU content 



Information element Length 


Remark 


Message dependent elements 


Last block (LB) 


1 


This bit shall be set to I2 because this PDU is appended to an 
applicable Move MBC Header 


Protect Flag (PF) 


1 




Feature elements 


CSBK Opcode (CSBKO) 


6 


Shall be set to the CSBKO of the first block of the multi-block 
CSBK 


Reserved 


4 


OOOO2 


Colour Code 


4 


Colour Code used for the destination physical channel 


Cdeftype 


4 


Meaning of CdefParms (see clause 7.2.19.7) 


Reserved 


2 


OO2 


CdefParms 


58 


information elements describing the logical / physical channel 
frequency relationship 



7.1.1.1.4 



Aloha (C_ALOHA) CSBK PDU 



Octet and 1 of the C_ALOHA CSBK PDU conforms to the LC format structure as defined in figure 7.1 in 

TS 102 361-1 [5] of the standard with the CSBKO replacing the FLCO. Octets 2 to 9 contain the C_ALOHA PDU 

specific information. The C_ALOHA PDU is illustrated in table 7.17. C_ALOHA PDUs are transmitted by a TSCC. 
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Table 7.17: C ALOHA PDU content 



Information element 


Length 


Remark 




Message dependent elements 


Last block (LB) 


1 


This bit shall be set to ^2 


Protect Flag (PF) 


1 




Feature elements 


CSBK Opcode (CSBKO) 


6 


Shall be set to 01 1001 2 


Feature set ID (FID) 


8 


Shall be set to 0000 OOOO2 


Reserved 


7 




Active_Connection 


1 


O2 - The TS does not have a connection with the network 
I2 - The TS has a connection with the network 


Mask 


5 




Service Function 


2 




NRand Wait 


4 




Reg 


1 


This bit is set if the TSCC demands MS register before becoming 


active 


Backoff 


4 


Backoff Number 


System Identity Code 


16 




MS Address 


24 


MS Individual Address 



7.1.1.1.5 



Announcements (C_BCAST) CSBK/MBC PDU 



Octet and 1 of the C_BCAST PDU conforms to the LC format structure as defined in figure 7.1 in TS 102 361-1 [5] 
of the standard with the CSBKO replacing the FLCO. Octets 2 to 9 contain the C_BCAST PDU specific information. 
The C_BCAST PDU is transmitted on the TSCC either as a single block CSBK or a Multi Block Control (MBC). 

The C BCAST PDU is illustrated in table 7.18. 
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Table 7.18: C BCAST PDU content 



Information element Length Remark 


Message dependent elements 


Last block (LB) 


1 


This bit shall be set to 1 2 for a single block CSBK or O2 if this is a MBC header 


Protect Flag (PF) 


1 




Feature elements 


CSBK Opcode (CSBKO) 


6 


Shallbesetto10 10002 


Feature set ID (FID) 


8 


Shall be set to 0000 OOOO2 


Announcement type 


5 


Defines which system parameters are being broadcast 


Broadcast Parms 1 


14 




Reg 


1 


This bit is set if the TSCC demands MS register before becoming active 


Backoff 


4 


Backoff Number 


System Identity Code 


16 




Broadcast Parms 2 


24 





The Announcement type PDU determines the category of Announcements: 

a) AnnounceAVithdraw TSCC. 

b) Specify call Timers. 

c) Vote now advice. 

d) Announce local time. 

e) Broadcast Mass Registration. 

f) Announce a logical physical channel relationship. 

g) Announce adjacent site information. 
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7.1.1.1.5.1 



Broadcast Absolute Parameters (BC_AP) appended MBC PDU 



The second block of the multi-block Broadcast Absolute Parameters MBC (announce logical/absolute frequency 
relationship) conforms to the format specified in table 7.19. The CdefParms PDU is specified in clause 7.2.19.7 and the 
physical characteristics described in annex C. 

Table 7.19: BC_AP appended Broadcast MBC PDU content 



Information element 


Length 


Remark 


Message dependent elements 


Last block (LB) 


1 


This bit shall be set to O2 because this PDU is appended to an 
applicable Announcement MBC Header 


Protect Flag (PF) 


1 




Feature elements 


CSBK Opcode (CSBKO) 


6 


Shall be set to the CSBKO of the first block of the multi-block CSBK 


Reserved 


8 




Cdeftype 


4 




Reserved 


2 




CdefParms 


58 


Information elements describing the logical / physical channel frequency 
relationship 



7.1.1.1.6 



Ahoy (AHOY) CSBK PDU 



Octet and 1 of the AHOY CSBK PDU conforms to the LC format structure as defined in figure 7.1 in 

TS 102 361-1 [5] of the standard with the CSBKO replacing the FLCO. Octets 2 to 9 contain the C_AHOY specific 

information. The generic AHOY PDU is illustrated in table 7.20. AHOY PDUs are transmitted by the TS. 

The AHOY PDU is transmitted by the TS as a single block CSBK. 
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Table 7.20: AHOY PDU content 



Information element Length Remark 


Message dependent elements 


Last block (LB) 


1 


This bit shall be set to ^2 


Protect Flag (PF) 


1 




Feature elements 


CSBK Opcode (CSBKO) 


6 


Shall be set to 01 IIOO2 


Feature set ID (FID) 


8 


Shall be set to 0000 OOOO2 


Service Options Mirror 


7 




Service Kind Flag 


1 


Meaning dependent on Service Kind 


Ambient Listening Service 


1 


O2 - The calling party has not requested ALS 


I2 - The calling party has requested ALS (See Note) 


IG 


1 


O2 - The Target address is an MS individual ID 


I2 - The Target address is a talkgroup 


Appended_Blocks 


2 


For a demand to the MS to send a multi-block CSBK, the number 
of appended data blocks 


Service Kind 


4 


Service for which this C AHOY is supporting 


Target address 


24 


Address of Called MS or talkgroup 


Source Address or Gateway 


24 


Address of calling party MS or gateway, or Authentication 
challenge value 


NOTE: ALS is only applicable for an individual MS voice call 



7.1.1.1.7 



Acknowledgement C_ACKD) TSCC Response CSBK PDU 



Octet and 1 of the Acknowledge Response (C_ACKD) CSBK PDU conforms to the LC format structure as defined in 
figure 7.1 in TS 102 361-1 [5] of the standard with the CSBKO replacing the FLCO. Octets 2 to 9 contain the 
Acknowledge Response specific information. The generic Acknowledge Response PDU is illustrated in table 7.21. 
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Figure 7.14 

NOTE: Acknowledgement Responses are transmitted by both TS and MS. 
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Table 7.21 : TS Acknowledgement Response PDU content 



Information element Length Remark 


Message dependent elements 


Last block (LB) 


1 


This bit shall be set to ^2 


Protect Flag (PF) 


1 




Feature elements 


CSBK Opcode (CSBKO) 


6 


Shall be set to10 00002 


Feature set ID (FID) 


8 


Shall be set to 0000 OOOO2 


Response Info 


7 


Supplementary response information 


Reason Code 


8 




Reserved 


1 


This bit shall be set to O2 


Target address 


24 


Address of Called MS 


Additional Information 
(Source Address) 


24 


Address of calling party MS or gateway 



Acknowledge Response PDUs are arranged into classes: 
C_ACKD - Positive Acknowledgement. 
C_NACKD - Negative Acknowledgement. 
C_QACKD - Queued. 
C_WACKD - Intermediate Acknowledgement. 



7.1.1.1.8 



Unified Data Transport Outbound Header (C_UDTHD) UDT PDU 



This PDU is a multi-block UDT conforming to the format specified in table 7.22. The number of UDT Appended data 
blocks is indicated by the Appended Blocks (UAB) information element. 

The UDT Appended Data Format is prescribed in annex B. 
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Figure 7.15 

NOTE: UDT Headers are transmitted by both TS and MS. 
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Table 7.22: Unified Data Transport Download Header PDU content 



Information element Length Remark 


Feature elements 


Elements defined in TS 102 361-1 [5] 


G/l (IG) 


1 


O2 = Destination is an individual MS address 


I2 = Destination is a Talkgroup address. Response not expected 


A 


1 


O2 = Response not expected if Destination is an individual MS 
address 


I2 = Response demanded if Destination is an individual MS 
address 


Emergency 


1 


O2 = This PDU is not supporting an emergency priority call 


I2 = This PDU is supporting an emergency priority call 


UDT Option Flag 


1 


See clause 7.2.12.2 


Format 


4 


OOOO2 


SAP 


4 


Service Access Point - OOOO2 for UDT 


UDT Format 


4 


Format of the data following the UDT Header 


Target_address or Gateway 


24 




Source address or Gateway 


24 




Pad Nibble 


5 




Reserved 


1 


02 


Appended_Blocks(UAB) 


2 


Number of Blocks appended to this UDT Header 
OO2 = 1 Appended Data UDT block 
OI2 = 2 Appended Data UDT blocks 
IO2 = 3 Appended Data UDT blocks 
1 12 = 4 Appended Data UDT blocks 


Supplementary_Flag(SF) 


1 


O2 = This UDT Header is carrying the data for a user initiated 

service (Short Data, Data Polling) 

I2 = This UDT Header is carrying supplementary data, supporting 

another Tier III service. 


Protect Flag (PF) 


1 


Reserved for Future Use 


Opcode (UDTHD) 


6 


Shall be set to 01 IOIO2 


NOTE: Shaded rows are information elements that are defined in TS 102 361-1 [5]. 



7.1.1.2 



TSCC Inbound channel CSBKs/UDTs transmitted by MS 



7.1.1.2.1 



Random Access Request (C_RAND) PDU 



Octet and 1 of the Random Access CSBK (C_RAND_CSBK) PDU conform to the LC format structure as defined in 
figure 7.1 in TS 102 361-1 [5] of the standard with the CSBKO replacing the FLCO. Octets 2 to 9 contain the Random 
Access Request specific information specified in table 7.23. Random Access Requests are sent by MS. 
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Figure 7.16 
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Table 7.23: Random Access Request PDU content 



Information element Length Remark 


Message dependent elements 


Last block (LB) 


1 


This bit shall be set to ^2 


Protect Flag (PF) 


1 




Feature elements 


CSBK Opcode (CSBKO) 


6 


Shall be set to 01 IIII2 


Manufacturers Feature ID 


8 


Shall be set to 0000 OOOO2 


Service Options 


7 




Proxy Flag 


1 


O2 - Number of Extended BCD digits for addressing through a 

gateway = 1 to 20 

^2- Number of Extended BCD digits for addressing through a 

gateway = 21 to 44 


Appended Supplementary Data 

ALS 

Accept/Reject 


2 


Information Element depends on Service being supported 


Appended Short Data 


2 


Number of appended CSBKs required to transport short data 


Service Kind 


4 


Service requested 


Target address or Gateway 


24 




Source address 


24 


Address of the requesting MS 



7.1.1.2.2 



C_Ackvitation (C_ACKVIT) CSBK PDU 



Octet and 1 of the C_ACKVIT CSBK PDU conforms to the LC format structure as defined in figure 7.1 in 

TS 102 361-1 [5] of the standard with the CSBKO replacing the FLCO. Octets 2 to 9 contain the C_Ackvitation specific 

information. The generic C_Ackvitation PDU is illustrated in table 7.24. C_Ackvitation PDUs are transmitted by MS. 

The C_Ackvitation PDU is transmitted by the MS as a single block CSBK. 
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Figure 7.17 
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Table 7.24: C Ackvitation PDU content 



Information element Length Remark 


Message dependent elements 


Last block (LB) 


1 


This bit shall be set to 1 2 for a single block CSBK or O2 for a all 
but the last block of a multi-block CSBK 


Protect Flag (PF) 


1 




Feature elements 


CSBK Opcode (CSBKO) 


6 


Shall be set to 01 111 O2 


Feature set ID (FID) 


8 


Shall be set to 0000 OOOO2 


Service Options Mirror 


7 




Service Kind Flag 


1 


Meaning dependent on Service Kind 


Reserved 


2 


OO2 


Appended_Blocks (UAB) 


2 


For a demand to the TS to send a multi-block CSBK, the number 
of appended data blocks 


Service Kind 


4 


Service for which this C_AHOY is supporting 


Target address 


24 


Address of Called MS 


Source Address or 
Gateway or Authentication 


24 


Address of calling party MS or gateway, or Authentication 
challenge value 



7.1.1.2.3 



C_Acknowledge (C_ACKU) MS Response CSBK PDU 



Octet and 1 of the Acknowledge Response CSBK PDU conforms to the LC format structure as defined in figure 7.1 in 
TS 102 361-1 [5] of the standard with the CSBKO replacing the FLCO. Octets 2 to 9 contain the Acknowledge 
Response specific information. The generic Acknowledge Response PDU is illustrated in table 7.25. 
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Figure 7.18 

NOTE: Acknowledgement Responses are transmitted by both TS and MS. 
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Table 7.25: MS Acknowledge Response PDU content 



Information element Length Remark 


Message dependent elements 


Last block (LB) 


1 


This bit shall be set to ^2 


Protect Flag (PF) 


1 




Feature elements 


CSBK Opcode (CSBKO) 


6 


Shall be set to 10 0001 2 


Feature set ID (FID) 


8 


Shall be set to 0000 OOOO2 


Response Info 


7 


Supplementary response information 


Reason Code 


8 




Reserved 


1 


This bit shall be set to O2 


Target address or 
Authentication 


24 


The Source Address from the TS PDU for which this 
acknowledgement is being transmitted or authentication challenge 
response if this acknowledgement is being transmitted as part of 
authentication challenge 


Additional Information 
(Source Address) 


24 


MS individual address that is transmitting the acknowledgement 



Acknowledge Response PDUs are arranged into classes: 
C_ACKU - Positive Acknowledgement. 
C_NACKU - Negative Acknowledgement. 



7.1.1.2.4 



Unified Data Transport Inbound channel Header (C_UDTHU) UDT PDU 



C_UDT PDUs are sent by TS and MS. This PDU is a multi-block UDT conforming to the format specified in 
table 7.26. The number of UDT Appended data blocks is indicated by the Appended Blocks (UAB) information 
element. 
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NOTE: UDT Headers are transmitted by both TS and MS. 
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Table 7.26: Unified Data Transport Inbound channel Header PDU content 



Information element Length Remark 


Feature elements 


Elements defined in TS 102 361-1 [5] 


G/l (IG) 


1 


O2 = Destination is an individual MS address 


^2 = Destination is a Talkgroup address. Response not expected 


A 


1 


O2 = Response not expected if Destination is an individual MS 
address 


^2 = Response demanded if Destination is an individual MS 
address 


Reserved 


2 


OO2 


Format 


4 


OOOO2 


SAP 


4 


Service Access Point - OOOO2 for UDT 


UDT Format 


4 


Format of the data following the UDT Header 


Target address or Gateway 


24 




Source address or Gateway 


24 




Pad Nibble 


5 




Reserved 


1 




Appended_Blocks(UAB) 


2 


Number of Blocks appended to this UDT Header 
OO2 = 1 Appended Data UDT block 
OI2 = 2 Appended Data UDT blocks 
IO2 = 3 Appended Data UDT blocks 
1 12 = 4 Appended Data UDT blocks 


Supplementary_Flag(SF) 


1 


O2 = This UDT Header is carrying the data for a user initiated 

service (Short Data, Data Polling) 

I2 = This UDT Header is carrying supplementary data, supporting 

another Tier III service. 


Protect Flag (PF) 


1 


Reserved for Future Use 


Opcode (UDTHU) 


6 


Shall be set to 01 1011 2 


NOTE: Shaded rows are information elements that are defined in TS 102 361-1 [5]. 



7.1.1.3 



Outbound channel CSBKs transmitted on a Payload Channel by a TS 



7.1.1.3.1 



Channel Grant (P_GRANT) CSBK/MBC PDU 



Channel Grant PDUs transmitted on the payload channel conform to the same structure as channel grant PDUs 
transmitted on the TSCC. When transmitting such a PDU on the payload channel, the TS shall retain all PDUs to the 
value from the TSCC channel grant PDU except the logical channel number (and absolute frequency if the channel 
grant PDU has an appended CSBK block. 

The Payload Channel Grant PDU is transmitted by the TSCC either as a single block CSBK or a Multi Block Control 
(MBC). For the Physical Channel Number Information Element: 

h) If the value = 0000 0000 OOOO2 the Physical Channel number is invaUd. 

i) If the value = 0000 0000 0001 2 to 1 1 1 1 1111 1 1 IO2, the Physical Channel number represent a logical channel 

number for the physical transmitter and receiver frequency. The Private Data Channel Grant PDU is 
transmitted by the TSCC as a single block CSBK. 

j) If the value = 1111 1111 1111 2, the Physical Channel number defines a multi -block CSBK where the absolute 
transmitter and receiver frequency is defined in a second block concatenated to this block (defined in 
clause 7.1.1.1.2). 
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Figure 7.20 
Table 7.27: Payload Channel Grant PDU Content 



Information element Length Remark 


Message dependent elements 


Last block (LB) 


1 


This bit shall be set to 1 2 for a single block CSBK or O2 if this is a MBC header 


Protect Flag (PF) 


1 




Feature elements 


CSBK Opcode (CSBKO) 


6 


Shall be set to 11 0011 2 


Feature set ID (FID) 


8 


Shall be set to 0000 OOOO2 


Logical Physical Channel 
Number 


12 


Payload Channel for the Call or an indicator that the absolute Tx & Rx 
frequency is specified in an appended CSBK block 


Logical Channel Number 


1 


O2 - TDMA channel 1 
I2-TDMA channel 2 


Reserved 


3 


OOO2 


Destination Address 


24 


Called party Individual MS Address, Gateway or Talkgroup 


Source address 


24 


Calling Party or Gateway 



7.1.1.3.2 



Clear (P_CLEAR) CSBK PDU 



Octet and 1 of the P_CLEAR CSBK PDU conforms to the LC format structure as defined in figure 7.1 in 

TS 102 361-1 [5] of the standard with the CSBKO replacing the FLCO. Octets 2 to 9 contain the P_Clear specific 

information illustrated in table 7.28. P_Clear is transmitted by the TS on a payload channel only and does not solicit a 

response. 
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Figure 7.21 
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Table 7.28: P Clear PDU Content 



Information element Length Remark 


Message dependent elements 


Last block (LB) 


1 


This bit shall be set to ^2 


Protect Flag (PF) 


1 




Feature elements 


CSBK Opcode (CSBKO) 


6 


Shallbesetto10 11102 


Feature set ID (FID) 


8 


Shall be set to 0000 OOOO2 


Logical Physical Channel 
Number 


12 


Channel to which the addressed party(s) shall move or an 
indicator that the absolute Tx and Rx frequency is specified 
in an appended CSBK block 


Reserved 


3 


OOO2 


IG 


1 


O2 - The Target Address is a MS ID 


I2 - The Target address is a talkgroup 


Target Address 


24 


Target MS ID, Talkgroup or ALLMSI (see note) 


Source Address 


24 


TSI 


NOTE: If the target address is ALLMSI then 10=02- 



The P_Clear PDU is transmitted by the TS either as a single block CSBK or a Multi Block Control (MBC). For the 
Physical Channel Number Information Element: 

a) If the value = 0000 0000 OOOO2 the applicable MS(s) shall move to the channel number of the control channel 
on which the MS was last confirmed. 

b) Physical Channel number is invalid. The Clear PDU is transmitted by the TS as a single block CSBK. 

c) If the value = 0000 0000 0001 2 to 1 1 1 1 1111 1 1 IO2, the Physical Channel number represent a logical channel 

number for the physical transmitter and receiver frequency. The Clear PDU is transmitted by the TSCC as a 
single block CSBK. 

d) If the value = 1111 1111 1111 2, the Physical Channel number defines a multi -block CSBK where the absolute 
transmitter and receiver frequency is defined in a second block concatenated to this block (defined in 

clause 7.1.1.1.2). 

In most Tier III networks the P_Clear PDU is used to clear all MS and talkgroups from a traffic channel so the traffic 
channel may be re-allocated for a new call. To effect this behaviour the Target Address is set to ALLMSI 



7.1.1.3.3 



Protect (P_PROTECT) CSBK PDU 



Octet and 1 of the P_Protect CSBK PDU conforms to the LC format structure as defined in figure 7.1 in 
TS 102 361-1 [5] of the standard with the CSBKO replacing the FLCO. Octets 2 to 9 contain the P_Protect specific 
information illustrated in table 7.29. P_Protect is transmitted by the TS on a payload channel only and does not solicit a 
response. The P_Protect PDU is transmitted by the TS as a single block CSBK. 
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Table 7.29: P Protect PDU content 



Information element 


Length Remark 


Message dependent elements 


Last block (LB) 


1 


This bit shall be set to ^2 


Protect Flag (PF) 


1 




Feature elements 


CSBK Opcode (CSBKO) 


6 


Shallbesetto10 111l2 


Feature set ID (FID) 


8 


Shall be set to 0000 OOOO2 


Reserved 


12 


0000 0000 OOOO2 


Protect Kind 


3 




IG 


1 




Target Address 


24 


MS Address or talkgroup 


Source Address 


24 


TS! 



7.1.1.3.4 



Ahoy (P_AHOY) CSBK PDU 



Octet and 1 of the AHOY CSBK PDU conforms to the LC format structure as defined in figure 7.1 in 
TS 102 361-1 [5] of the standard with the CSBKO replacing the FLCO. Octets 2 to 9 contain the P_AHOY specific 
information illustrated in table 7.20. The P_AHOY is transmitted by the TS on a payload channel and if addressed to a 
talkgroup does not solicit a response. 
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Figure 7.23 



7.1.1.3.4.1 



MS Presence Check 



The TS may send a MS Presence Check P_AHOY on the payload channel to check if an individually addressed MS is 
present on the payload channel. 

7.1 .1 .3.4.2 MS Authentication Check 

The TS may send a MS Authentication Check P_AHOY on the payload channel to challenge an MS. 

7.1 .1 .3.4.3 Talkgroup Presence Check 

The TS may send a Talkgroup Presence Check P_AHOY on the payload channel to check if at least one talkgroup is 
present on the payload channel. 



7.1.1.3.5 



P_Acknowledgement response 



Acknowledgement PDUs transmitted on the payload channel conform to the same structure as acknowledgement PDUs 
transmitted on the TSCC. 
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7.1.1.4 



Inbound channel CSBKs transmitted on a Payload Channel by MS(s) 



7.1.1.4.1 



Random Access Request PDU 



Random Access PDUs transmitted on the payload channel conform to the same structure as Random Access PDUs 
transmitted on the TSCC. However the only random access Service _Kind permitted on the payload channel shall be to 
request an include service. 
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7.1.1.4.2 



P_ACK Acknowledgements 



Acknowledgement PDUs transmitted on the payload channel conform to the same structure as acknowledgement PDUs 
transmitted on the TSCC. 
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7.1.1.4.3 



P MAINT Maintenance PDUs 



Octet and 1 of the P_MAINT CSBK PDU conforms to the LC format structure as defined in figure 7.1 in 
TS 102 361-1 [5] of the standard with the CSBKO replacing the FLCO. Octets 2 to 9 contain the P_MAINT specific 
information illustrated in table 7.30. P_MAINT is transmitted by MS on a payload channel only. The P_MAINT PDU is 
transmitted by MS as a single block CSBK. 
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Table 7.30: P MAINT PDU content 



Information element 


Length Remark 


Message dependent elements 


Last block (LB) 


1 


This bit shall be set to ^2 


Protect Flag (PF) 


1 




Feature elements 


CSBK Opcode (CSBKO) 


6 


Shall be set to 10 IOIO2 


Feature set ID (FID) 


8 


Shall be set to 0000 OOOO2 


Reserved 


12 




Maint Kind 


3 




Reserved 


1 




Target Address 


24 


TSI 


Source Address 


24 


MS Address 



7.1 .2 Short Link Control PDUs 



7.1.2.1 



System Parameters 



Bits to 3 of Octet of the System Parameters (S YS_Parms) Short LC PDU conform to the Short LC format structure 
as defined in figure 7.2 of clause 7.1 in TS 102 361-1 [5]. Octets 1 to 3 contain the System Parameters specific 
information. The SYS Parms PDU is illustrated in table 7.31. 
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Table 7.31 : SYS Parms PDU Content 



Information element Length Value Remark 


Elements 


Short LC Opcode (SLCO) 


4 


001 O2 




MODEL 


2 


OO2 


Tiny Network Model 


OI2 


Small Network Model 


IO2 


Large Network Model 


II2 


Huge Network Model 


NET 


12 




Network and Site Definition 


SITE 


Reg 


1 


O2 


This TSCC does not require the MS to register 
before becoming active 


I2 


This TSCC requires the MS to register before 
becoming active 


Common Slot Counter 


9 




Common Slot Counter 



7.2 Layer 3 information element coding 

The following clauses contain descriptions of the information elements contained within layer 3 PDUs, and provide a 
description of what the elements represent in relation to their bit representation. The structure of the tables is as follows: 

• the information element column gives the name of the element; 

• the element length column defines the length of the element in bits; 

• the value column denotes fixed values or a range of values; 

• the remarks column defines the meaning of the information element against each of its bit represented values. 

7.2.1 Mask 

The Mask information element has a length of 5 bits and is illustrated in table 7.32. 

Table 7.32: Mask 



Information element 


Length 


Value 


Remark 


Mask 


5 


0to24 


Value in the range to 24 (decimal) 



7.2.2 Service Function 

The Service Type information element has a length of 2 bits and is illustrated in table 7.33. 

Table 7.33: Service Function 



Information element 


Length 


Value 


Remark 


Service Function 


2 


OO2 


Random Access invited for all Services 


OI2 


Random Access Invited for Services that require a 

payload channel 

Random Access Invited for registration requests 


IO2 


Random Access Invited for Services that do not 

require a payload channel 

Random Access Invited for registration requests 


II2 


Random Access invited for random access 
registration requests only 
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7.2.3 NRand_Wait 

The Nrand_Wait information element has a length of 4 bits and is illustrated in table 7.34. The TSCC shall specify, 
using NRand_Wait, the delay (in TDMA-frames) a MS must wait before deciding to retransmit and choose another slot 
from a new random-access-frame. 

Table 7.34: NRand Wait 



Information element 


Length 


Value 


Remark 








TSCC response to a Random Access Request 








= response in the next TDMA-frame 








1 - MS shall wait for 1 TDMA frame 








2 - MS shall wait for 2 TDMA frames 








3 - MS shall wait for 3 TDMA frames 








4 - MS shall wait for 4 TDMA frames 








5 - MS shall wait for 5 TDMA frames 








6 - MS shall wait for 6 TDMA frames 


NRand_Wait 


4 


0to15 


7 - MS shall wait for 7 TDMA frames 

8 - MS shall wait for 8 TDMA frame 

9 - MS shall wait for 9 TDMA frames 

1 - MS shall wait for 1 TDMA frames 

11 - MS shall wait for 1 1 TDMA frames 

1 2 - MS shall wait for 1 2 TDMA frames 

1 3 - MS shall wait for 1 3 TDMA frames 

1 4 - MS shall wait for 1 5 TDMA frames 

1 5 - MS shall wait for 24 TDMA frames 



7.2.4 Reg 

The Reg information element has a length of 1 bit and is illustrated in table 7.35. 

Table 7.35: Reg 



Information element 


Length 


Value 


Remark 


Reg 


1 


O2 


MSs are not required to register 


I2 


MSs are required to register 



7.2.5 Backoff 

The Backoff information element has a length of 4 bits and is illustrated in table 7.36. 

Table 7.36: Backoff Number 



Information element 


Length 


Value 


Remark 


Backoff 


4 





- Reserved 


1 


Backoff TDMA Frame length = 1 


2 


Backoff TDMA Frame length = 2 


3 


Backoff TDMA Frame length = 3 


4 


Backoff TDMA Frame length = 4 


5 


Backoff TDMA Frame length = 5 


6 


Backoff TDMA Frame length = 8 


7 


Backoff TDMA Frame length = 1 1 


8 


Backoff TDMA Frame length = 15 


9 


Backoff TDMA Frame length = 20 


10 


Backoff TDMA Frame length = 26 


11 


Backoff TDMA Frame length = 33 


12 


Backoff TDMA Frame length = 41 


13 


Backoff TDMA Frame length = 50 


14 


Backoff TDMA Frame length = 70 


15 


Backoff TDMA Frame length = 100 
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7.2.6 System Identity Code 

The System Identity Code information element has a length of 16 bits and is illustrated in table 7.37. 

Table 7.37: System Identity Code 



Information element 


Length 


Value 


Remark 


System Identity Code 
C SYScode 


16 


value 


System identity Code transmitted on the TSCC 



7.2.7 Responsejnfo 

The Responsejnfo information element contains supplementary information in acknowledgement PDUs. It has a 
length of 7 bits and is illustrated in table 7.38. 

Table 7.38: Responsejnfo 



Information element Length Alias/value 


Remark 


Acknowledgement Reason Code = Message_Accepted (0100 OOOO2) 


Responsejnfo 


7 


PowerSAve_Offset 


Acknowledgement to a random access 
registration request that invokes power 
save (see clause 6.4.7). The target 
address is a MS individual ID 


All other acknowledgement Reason Codes 


IG 


1 


O2 


The Target address is an MS individual 
ID or Gateway 


I2 


The Target address is a talkgroup 


Response_Check 


6 


Value 


The six least significant bits from the 
NET + SITE elements of the 
C_SYScode transmitted by the TSCC 
(see note) 


NOTE: The bits are 8, 7, 6, 5, 4 and 3 illustrated in figure 6.19. 



7.2.8 Reason 

The Reason information element has a length of 8 bits and is illustrated in tables 7.39 to 7.42. Separate tables are 
illustrated for the classifications C_ACK, C_NACK, C_QACK, C_WACK. 

The Reason bits are set out asttdaaaaa. 

tt - ACK type, OO2 = NACK; 0X2 = ACK; IO2 = QACK; 1 12 = WACK. 

d - direction, I2 = TS to MS; O2 = MS to TS, or transmitted by a TS to mirror the acknowledgement sent by a MS to 
other applicable parties. 

a a a a a - acknowledgement reason. 

There are instances whereby the Reason Code for an acknowledgement from a MS must be retransmitted by the TS. In 
this case the reason code from the MS is mirrored exactly by the TS. Such an acknowledgement is described in the 
present document as a Mirrored_Reason. 
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Table 7.39: Answer Response C_ACK 



Information 
element 


Length 


Value Alias Remark 


Acknowledgement Transmitted by a TS 
Message Accepted by the MS 


Reason 


8 


OIIOOOOO2 


Message_Accepted 


Message accepted by TS - Proceed 


OIIOOOOI2 


Store_Forward 


Call is placed in store and forward buffer for 
onward transmission when the called MS 
registers 


0110 001 O2 


Reg_Accepted 


Request from MS to register has been 
accepted 








Acknowledgement Transmitted by a MS 
Message Accepted by the TS (may be forwarded by the TS) 


OIOOOIOO2 


MS_Accepted 


Message accepted by MS 


OIOOOIOI2 


CallBack 


Called MS is indicating to the TS that it will 
call back later 






OIOOOIIO2 


MS_ALERTING 


MS alerting but not yet RFC 
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Table 7.40: Answer Response C_NACK 



Information 
element 



Length 



Value 



Mnemonic 



Remark 



Message/Service rejected by network (TS) 



Reason 



0010 0000:, 



0010 0001. 



0010 0010:, 



0010 0011. 



OOlOOIOOo 



00100101. 



OOlOOIlOo 



00100111. 



OOlOIOOOo 



0010 1001. 



0010 1010:, 



0010 1011. 



OOlOIIOOo 



0010 1101. 



ooiomOo 



Not_Supported 



Perm User Refused 



Temp_User_Refused 



Transient_Sys_Refused 



NoregMSaway_Refused 



MSaway_Refused 



Div Cause Fail 



SYSbusy_Refused 



SYS_NotReady 



Call Cancel Refused 



Reg_Refused 



Reg_Denied 



IP Connection failed 



MS_Not_Registered 



Called_Party_Busy 



Network does not support this service 



Request refused because service has 
not been authorized for this user 
(permanent) (Meaning of permanent 
is manufacturer specific) 



Request refused because service is 
not currently authorized for this user 
(temporary) (Meaning of temporary is 
manufacturer specific) 



Request refused because the service 
is not available to this network at this 
time 



Request refused because called party 
is not in radio contact (and is not 
registered with the network) 



Request refused because called party 
is not in radio contact (but is 
registered with the network) 



Call cannot be processed because 
the MS has diverted its calls 



Request refused because the network 
is experiencing congestion (Network 
Overload) 



Request refused because the network 
is not ready (try later) 



Request to cancel a caW has been 
refused i.e. the call may still mature 



Request from a MS to register has 
been refused 



Request from a MS to register has 
been denied 



Request from a MS to inform IP 
connection advice failed 



This system requires MS to be 
registered before accepting a user 
service request. The MS is not 
registered 



The called party is busy and the 
network does not wish to queue the 
call 



Message/Service rejected by MS (may be forwarded by TS) 



0000 OOOOo 



0001 0001. 



0001 001 Oo 



0001 0011. 



0001 0100:, 



0001 0101. 



MSNot_Supported 



LineNot_Supported 



StackFull Refused 



EuipBusy_Refused 



Recipient_Refused 



Custom Refused 



MS does not support this service or 
feature 



Request refused because service is 
not supported by the called party 
(Line) 



Request refused because the called 
party's internal call stack is full and is 
not employing a FIFO 



Request refused because called party 
ancillary equipment is busy 



Request refused by called party user 
(like in FOACSU) 



Request refused due to custom- 
defined reason 
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Table 7.41 : Answer Response C_QACK 



Information 
element 


Length 


Value 


Alias Remark 


Acknowledgement Transmitted by a TS 


Reason 


8 


IOIOOOOO2 


Queued-for-resource 
(e.g. payload channel) 


IVIessage accepted by TS - more signalling to 
follow 


IOIOOOOI2 


Queued-for-busy 


Called party is engaged in another call 



Table 7.42: Answer Response C_WACK 



Information 
element 


Length 


Value 


Alias Remark 


Acknowledgement Transmitted by a TS 


Reason 


8 


IIIOOOOO2 


Wait 


Message accepted by TS - more signalling to 
follow 



7.2.9 Digits 

The Digits information element represents dialled digits coded as table 7.43. 

Table 7.43: Digits 



Information 
element 


Length 


Value 


Alias 


Remark 


Digits 


4 


OOOO2 


Digit '0' 




0001 2 


Digit '1' 




001 O2 


Digit '2' 




00112 


Digit '3' 




01002 


Digit '4' 




01012 


Digit '5' 




01102 


Digit '6' 




01112 


Digit 7' 




10002 


Digit '8' 




10012 


Digit '9' 




10102 


Digit '*' 


* character 


10112 


Digit '#' 


# character 


11002 


Reserved 




11012 


Reserved 




11102 


Reserved 




11112 


Digit 'NULL' 





7.2.10 Active_Connection 

This information element specifies if the TS has an active network connection with the rest of the network, 
i.e. communication with other radio sites is possible. 

Table 7.44: Active Connection 



Information element 


Length 


Value 


Alias 


Remark 


Active Connection 


1 


O2 




O2 - The TS does not have a connection with the 
network 


I2 




I2 - The TS has a connection with the network 
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7.2.11 Packet Mode 

The Packet Mode information element has a length of 1 bit and is illustrated in table 7.45. 

Table 7.45: Packet Mode 



Information element 


Length 


Value 


Alias 


Remark 


Packet Mode 


1 


O2 




O2 - Payload Channel uses 2:1 mode 


I2 




I2 - Payload Channel uses 1 :1 mode 



7.2.12 Service_Kind 

The Service_Kind information element has a length of 4 bits and is illustrated in table 7.46. 

Table 7.46: Service Kind information element 



Information element 


Length 


Value 


Remark 


Service_Kind 


4 


OOOO2 


Individual Voice Call Service (Include Voice Individual 
Call Service if sent on a payload channel) 


0001 2 


Talkgroup Voice Call Service (Include Voice Talkgroup 
Call Service if sent on a payload channel) 


001 O2 


Individual Packet Data Call Service 


00112 


Packet Data Call Service to a talkgroup 


01002 


Individual Short Data Call Service 


01012 


Talkgroup Short Data Call Service 


01102 


Short Data Polling Service 


01112 


Status Transport Service 


10002 


Call Diversion Service 


10012 


Call Answer Service 


10102to11002 


Reserved 


11012 


Supplementary Service 


11102 


Registration/Authentication Service (and 
deregistration)/MS Radio Check 


11112 


Cancel Call Service 
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7.2.12.1 Service_Kind_Flag 

The Service_Kind_Flag information element has a length of 1 bit and is illustrated in table 7.47. The meaning of 
Service_Kind_Flag supports the Service_Kind information element. The meaning of the Service_Kind_Flag depends on 
the message containing this information element. 

Table 7.47: Service_Kind_Flag information element 



Service 
Kind 


Message 


Service 
Kind_Flag_ 
Value 


Remark 


TSCC Channel 


OOOO2 


C_AHOY Voice Service Individual Radio Check 


02 


Check if called MS is in radio contact 
and can accept this call immediately. 
(OACSU) 


I2 


checks whether called MS is ready to 
accept speech or data call. 
(FOACSU) 


0001 2 


C_AHOY Voice Service Talkgroup Radio Check 


02 


Check if at least one member of the 
called talkgroup is in radio contact 


001 O2 


C_AHOY Packet Data individual radio check 


02 


Check if called MS is in radio contact 


00112 


C_AHOY Packet Data talkgroup radio check 


02 


Check if at least one member of the 
called talkgroup is in radio contact 


01002 


Individual Short Data Call Service 


02 


Not Applicable 


01012 


Talkgroup Short Data Call Service 


02 


Not Applicable 


01102 


Short Data Polling Service 


02 


Not Applicable 


01112 


Status Transport Service 


02 


Not Applicable 


10002 


Call Diversion Service 


02 


Not Applicable 


10012 


P_AHOY Radio Check to an individual MS 
address 


02 


General check for presence 
irrespective of the Service being 
supported 


P_AHOY Radio Check to a talkgroup 


I2 


10102to 
IIOO2 


Reserved 


02 


Reserved 


IIOI2 
(see note) 


C_AHOY Stun/Revive 


02 


Stun 


I2 


Revive 


C_AHOY Kill 


02 


Not Applicable 


IIIO2 


Registration/Authentication Challenge/MS radio 
check 


02 


Not Applicable 


IIII2 


Cancel Call Service 


02 


Not Applicable 


Payload Channel 


OOOO2 


P_AHOY Voice Service Individual Radio Check 


02 




0001 2 


P_AHOY Voice Service Talkgroup Radio Check 


02 




001 O2 


P_AHOY Packet Data individual radio check 


02 




00112 


P_AHOY Packet Data talkgroup radio check 


02 




10012 


P_AHOY Radio Check to an individual MS 
address 


02 


General check for presence 
irrespective of the Service being 
supported 


P_AHOY Radio Check to a talkgroup 


I2 


11112 


P_AHOY clear an individual MS from a voice 
payload channel 


02 


O2 Indicates that the target is an 
individual Address 


11112 


P_AHOY clear a talkgroup from a voice payload 
channel 


I2 


I2 Indicates that the target is a 
talkgroup 


NOTE: Service_Kind = 1 1 01 2 is the supplementary data service. The purpose is further defined by the Gateway 
ID defined in that PDU. 
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7.2.12.2 UDT_Option_Flag 

Table 7.48: UDT_Option_Flag information element 



UDT is supporting 


Message 


UDT_Option_ 
Flag Value 


Remark 


Voice Service (Service Kind - OOOO2) 
Packet Data (Service_Kind - 001 O2) 


UDTHD Outbound 
PDU carrying 
Supplementary Data 


02 


Check if called MS is in radio contact 
and can accept this call immediately. 
(OACSU) 


I2 


checks whether called MS is ready to 
accept speech or data call. 
(FOACSU) 


All other Services 


UDTHD 


02 


Reserved 



7.2. 1 3 Service_Options 

The number of Service_Options that are applicable is dependent on the DMR service requested. The Service_Options 
information element has a length of 7 bits and is illustrated for each applicable service in clauses 7.2.13.1 to 7.2.13.9. 

7.2.1 3.1 Service_Options for a Voice Service Request 

The Service_Options information for the Voice Service request is illustrated in table 7.49. 

Table 7.49: Service_Options for Voice Service Request 



Information element 


Length 


Value 


Remarl< 


Emergency 




O2 


Non-emergency service 


I2 


Emergency service 


Privacy 




O2 


(See note 1 ) 


Supplementary Data 




O2 


No Supplementary Data Transfer Service required for 
this call 


I2 


Supplementary Data Transfer Service requested for 
this call 


Broadcast 




O2 


Non-broadcast service 


I2 


Broadcast service (see note 3) 


Open Voice Call Mode (OVCM) 




O2 


Non-OVCM call 


I2 


OVCM call 


Priority level 


2 


OO2 


No priority 


OI2 


Priority 1 (see note 2) 


IO2 


Priority 2 (see note 2) 


II2 


Priority 3 (see note 2) 


NOTE 1 : Privacy is not defined in the present document. 
NOTE 2: Priority 3 is the highest priority. 
NOTE 3: Broadcast is applicable to talkgroups. 
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7.2.13.2 Service_Options for a Packet Data Service Request 

The Service_Options information for the Packet Data Service request is illustrated in table 7.50. 
Table 7.50: Service_Options for Packet Data Service Request 



Information element 


Length 


Value 


Remark 


Emergency 




02 


Non-emergency service 


I2 


Emergency service 


Privacy 




02 


Privacy (see note 1 ) 


Supplementary Data 




02 


No Supplementary Data Transfer Service required for 
this call 


I2 


Supplementary Data Transfer Service requested for 
this call 


Hi Rate 




02 


Payload channel expects single slot data timing 


I2 


Payload channel expects dual slot data timing 


Open Voice Call Mode (OVCM) 




02 


Non-OVCM call 


I2 


OVCM call 


Priority level 


2 


002 


No priority 


012 


Priority 1 (see note 2) 


102 


Priority 2 (see note 2) 


112 


Priority 3 (see note 2) 


NOTE 1 : Privacy is not defined in the present document. 
NOTE 2: Priority 3 is the highest priority. 
NOTE 3: Broadcast is applicable to talkgroups. 



7.2.13.3 Service_Options for a Call Diversion Service Request 

The Service_Options information for the call diversion Service request is illustrated in table 7.51. The Divert Kind 
information element determines to which call service the call diversion shall be applicable. 

Table 7.51 : Service_Options for Call Diversion Service Request 



Information element 


Length 


Value 


Remark 


Emergency 


1 


02 


Not applicable 


Privacy 


1 


02 


See note 


Divert Set/Clear 


1 


02 


Clear Call Diversion 


I2 


Set Call Diversion 


Divert Kind 


1 


Active 1 2 
Inactive O2 


Divert applicable to Voice Calls 


1 


Divert applicable to Packet Data Calls 


1 


Divert applicable to Short Data Calls 


1 


Divert applicable to Status Calls 


NOTE: Privacy is not defined in the present document. 
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7.2.13.4 Service_Options for a Registration Service Request 

The Service_Options information for the registration service request is illustrated in table 7.52. 
Table 7.52: Service_Options for the Registration Service 



Information element 


Length 


Value 


Remark 


Reserved 


1 


02 




Privacy 


1 


02 


(See note) 


IPJnform 


1 


02 


IVIS is not advising IP connection 


I2 


IVIS is advising IP connection 


PowerSave_RQ 


3 


0002 


Power Save not requested 


001 2 to 

1112 


Power Save requested 


Reg_Dereg 


1 


02 


If IP_lnform=02 the IVIS is attempting to de-register 
If IP_lnform=l2the IVIS is deleting an IP connection 


12 


If IP_lnform=02 the MS is attempting to register 

If IP_lnform=l2the MS is attempting to register and/or adding 

an IP connection 


NOTE: Privacy is not defined in the present document. 



7.2.13.5 Service_Options for an Include Call Service Request 

The Service_Options information for the include service request is illustrated in table 7.53. Include call service requests 
shall be restricted to the payload channel. 

Table 7.53: Service_Options for the Include Call Service 



Information element 


Length 


Value 


Remark 


Reserved 


1 


O2 




Privacy 


1 


O2 


See note 


Reserved 


5 


OOOO2 




NOTE: Privacy is not defined in the present document. 



7.2.1 3.6 Service_Options for a Status Transport Request 

The Service_Options information for the Status Transport Request is illustrated in table 7.54. The Status Transport call 
service requests shall be restricted to the control channel. 

Table 7.54: Service_Options for the Status Transport Service 



Information 
element 


Length 


Value 


Remark 


IG 


1 


02 


The target address is an MS individual ID 


I2 


The target address is a talkgroup 


Supplementary_user 
Data 


1 


02 


No supplementary_user data transfer 
requested 


I2 


Supplementary_user data is requested for 
this call 


Status (most 
significant 5 bits) 


5 


value 


Most significant 5 bits of the status to be 
transported, (see note) 


NOTE: The status is not part of the Service options but is illustrated in this clause for 
clarity. 
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7.2.1 3.7 Service_Options for the Short Data Service 

The Service_Options information for the Packet Data Service request is illustrated in table 7.55. 
Table 7.55: Service_Options for Short Data Service Request 



Information element 


Length 


Value 


Remark 


Emergency 


1 


O2 


Not applicable - O2 


Privacy 


1 


O2 


Privacy (see note) 


Supplementary Data 


1 


O2 


No Supplementary Data Transfer Service required for 
this call 


I2 


Supplementary Data Transfer Service requested for 
this call 




1 


O2 


Not applicable - O2 


Open Voice Call Mode (OVCM) 


1 


O2 


Not applicable - O2 


Appended_Short Data 


2 


OO2 


Number of appended UDTs required transport short 
data 


NOTE: Privacy is not defined in the present document. 



7.2.1 3.8 Service Options for the Supplementary Data Service 

The Service_Options information for the Packet Data Service request is illustrated in table 7.56. 

Table 7.56: Service_Options for Supplementary Data Service Request 



Information element 


Length 


Value 


Remark 


Emergency 




O2 


Not applicable - O2 


Privacy 




O2 


Privacy (see note) 






O2 


Not applicable - O2 






O2 


Not applicable - O2 






O2 


Not applicable - O2 


Appended_Short Data 


2 


OO2 


Number of appended UDTs required transport 
supplementary data 


NOTE: Privacy is not defined in the present document. 



7.2.13.9 Service Options for a Short Data Polling Request 

The Service_Options information for the Packet Data Service request is illustrated in table 7.57. 

Table 7.57: Service_Options for Short Data Polling Service Request 



Information element 


Length 


Value 


Remark 


Emergency 


1 


O2 


Not applicable - O2 


Privacy 


1 


O2 


Privacy (see note) 


Supplementary Data 


1 


O2 


Not applicable - O2 


Polling Format 


4 


O2 


Format of the data to be polled 


NOTE: Privacy is not defined in the present document. 



7.2.14 Service_Options_Mirror 

The Service_Options_Mirror information element is transmitted in C_AHOY PDUs. 

If the C_AHOY PDU has been transmitted as an immediate (or delayed) acknowledgement to a C_RAND Service 
request, the Service_Options_Mirror is set to the Service_Options information element from the C_RAND PDU. 
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7.2.1 4.1 Service_Options_Mirror for MS Authentication 

If the C_AHOY PDU has been transmitted as the result of a polHng PDU from the TSCC for Authentication, then the 
Service_Option_Mirror shall be set to the values specified in table 7.58. 

Table 7.58: Service_Options_Mirror for MS Authentication Poll 



Information element 


Length 


Value 


Remark 


Service_Options_Mirror 


Reserved 


1 


O2 




Privacy 


1 


O2 


See note 


Reserved 


5 


OOOO2 




NOTE: Privacy is not defined in the present document. 



7.2.1 4.2 Service_Options_Mirror for MS Stun/Revive 

If the C_AHOY PDU has been transmitted as the result of a polling PDU from the TSCC for MS stun/revive then the 
Service_Option_Mirror shall be set to the values specified in table 7.59. 

Table 7.59: Service_Options_Mirror for MS Stun/Revive Poll 



Service_Options_l\/lirror 


Reserved 


1 


O2 




Privacy 


1 


O2 


See note 


Reserved 


5 


OOOO2 




NOTE: Privacy is not defined in the present document. 



NOTE: Stun/Revive is a secondary service. 

7.2.14.3 Service_Options_Mirror for MS Kill 

If the C_AHOY PDU has been transmitted as the result of a polling PDU from the TSCC for MS stun/revive then the 
Service_Option_Mirror shall be set to the values specified in table 7.60. 

Table 7.60: Service_Options_Mirror for MS Kill 



Service_Options_l\/lirror 


Reserved 


1 


O2 




Privacy 


1 


O2 


See note 


Reserved 


5 


OOOO2 




NOTE: Privacy is not defined in the present document. 



7.2.15 Proxy Flag 

For calls to destinations connected through a TS gateway, the proxy flag indicates the number of Appended Data UDTs 
needed to upload the address of the final destination. For a call to a PABX or the PSTN, one appended data UDT will 
carry up to 20 dialled digits and two appended data UDTs will carry up to 44 dialled digits. 
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Table 7.61 : Proxy Flag information element 



Information element 


Length 


Value 


Remark 


Proxy Flag 


1 


O2 


Number of appended data MBCs needed to upload 
the final destination address = 1 
Number of Extended BCD digits for addressing 
through a PSTN/PABX gateway = 1 to 20. For IP 
gateway extended address is IPV4 


I2 


Number of appended data UDTs needed to upload 
the final destination address = 2 
Number of Extended BCD digits for addressing 
through a PSTN/PABX gateway = 21 to 44. For IP 
gateway extended_address is IPV6Number 



7.2.16 POL_FMT 

Specifies the format of polled data from the Short Data Polling procedures specified in clause 6.6.5.3. 

Table 7.62: POL FMT information element 



Information 
element 


Length 


Value 


Remark 


POL_FMT 


4 


OOOO2 


Binary 


0001 2 


IVIS Addresses 


001 O2 


4 bit BCD 


00112 


ISO 7 bit character set (ISO/IEC 646 [11]) 


01002 


ISO 8 bit character set (ISO/IEC 8859 [12]) 


01012 


NIVIEA location information 


01102 


IP address 


01112 


16 bit Unicode characters 


10002 


Reserved 


10012 


Reserved 


10102 


Reserved 


10112 


Reserved 


11002 


Reserved 


11012 


Reserved 


11102 


Reserved 


11112 


Reserved 



7.2. 1 7 Appended_ Block 

If the Supplementary Data Service has been invoked as an option with other voice or data services, the Appended 
Supplementary Data information element is used to pass the number of Appended Data UDTs needed to upload the 
Supplementary Data. 

If the Short Data Service has been invoked, the Appended Short Data information element is used by an MS to pass the 
number of Appended Data UDTs needed to upload the Short Data. 
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Table 7.63: Appended Supplementary Data information element 



Information element 


Length 


Alias 


Value 


Remark 


Appended_Block 


2 


UAB 


OO2 


Number of appended data UDTs needed to upload 
the supplementary data = 1 


OI2 


Number of appended data UDTs needed to upload 
the supplementary data = 2 


IO2 


Number of appended data UDTs needed to upload 
the supplementary data = 3 


II2 


Number of appended data UDTs needed to upload 
the supplementary data = 4 



7.2.18 Opcode 

The Opcode information element specifies the function of a UDT Header. 

Table 7.64: Opcode 



Information element 


Length 


Value 


Remark 


Opcode 


6 


00 OOOO2 


MBC is a UDT header 


00 0001 2 
to 11 IIII2 


Reserved 



7.2.19 Announcement type 

The Announcement type Format Code information element has a length of 5 bits and is illustrated in figure 7.2. 

Table 7.65: Announcement type 



Information element 


Length 


Value 


Alias 


Remark 


Announcement_type 


5 


OOOO2 


Ann-WD_TSCC 


Announce/Withdraw TSCC 


0001 2 


CallTimer_Parms 


Specify Call Timer Parameters 


000102 


Vote_Now 


Vote Now Advice 


000112 


Local_Time 


Broadcast Local Time 


001002 


MassReg 


Mass_Registration 


001012 


Chan_Freq 


Announce a logical channel / frequency 
relationship 


001102 


Adjacent_Site 


Adjacent Site information 


0011l2to1 
IIOI2 




Reserved 


1 IIIO2 




Manufacturer Specific 


1 IIII2 




Manufacturer Specific 
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7.2.1 9.1 Announce/Withdraw TSCC (Ann-WD_TSCC) 

Table 7.66: Announce/Withdraw TSCC 



Information 
element 


Length 


Value 


Alias 


Remark 


Broadcast 
Parms 1 


4 


O2 




Reserved 


4 


Value 




Colour code for CH_1 (default=00002) 


4 


Value 




Colour Code for CH_2 (default=00002) 


1 


O2 


AW_FLAG1 


AddBCAST_CH1 to hunt list 


I2 




Withdraw BCAST_CH1 from hunt list 


1 


O2 


AW_FLAG2 


Add BCAST_CH2 to hunt list 


I2 




Withdraw BCAST_CH2 from hunt list 


Broadcast 
Parms 2 


12 


or 1 to 
4095 


BCAST_CH1 


CHNULL or Logical Physical Channel Number 


12 


or 1 to 
4095 


BCAST_CH2 


CHNULL or Logical Physical Channel Number 



7.2.1 9.2 Specify Call Timer Parameters (CallTimer_Parms) 

Table 7.67: Specify Call Timer Parameters 



Information 
element 


Length 


Value 


Alias 


Remark 


Broadcast 
Parms 1 


9 


O2 


T_EMERG_TIMER 


MS uses its Internal Emergency Timer 


1 to 510 


Call Timer for Emergency Calls 


511 


Emergency Call Timer is Infinity 


5 





T_PACKET_TIMER 


MS uses its Internal Packet Timer 


1 to 30 


Call Timer for Packet Data 


31 


Packet Call Timer is Infinity 


Broadcast 
Parms 2 


12 





T_MS-MS_TIMER 


MS uses its Internal Timer for MS to MS calls 


1 to 4 094 


Call Timer for MS to MS Calls 


4 095 


MS to MS Call Timer is Infinity 


12 





T_MS-LINE_TIMER 


MS uses its Internal Timer for line connected calls 


1 to 4 094 


Call Timer for Line Connected calls 


4 095 


Line Connected Call Timer is Infinity 



7.2.1 9.3 Vote Now Advice (Vote_Now) 

Table 7.68: Vote Now Advice 



Information 
element 


Length 


Value 


Alias 


Remark 


Broadcast 
Parms 1 


14 






Most Significant 14 bits of the System Identity 
Code of the TSCC being assessed 


Broadcast 
Parms 2 


12 


0000 0000 OOOO2 




Reserved 


12 


1 to 4095 


CH VOTE 


Physical Channel Number to be assessed 
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7.2.19.4 Broadcast Local Time (Local_Time) 



Table 7.69: Broadcast Local Time 



Information 
element 


Length 


Value 


Alias 


Remark 


Broadcast 
Parms 1 


5 




B_DAY 


Day of the Month 1 to 31 (or if date is not being 
broadcast) 


4 




B_MONTH 


IVIonth 1 to 12 (or if month is not being 
broadcast) 


5 




UTC_OFFSET 


Offset between local hours and UTC hours (as a 
number in the range to 23 (or 1 1 1 1 1 2 if offset is 
not being broadcast)) 


Broadcast 
Parms 2 


5 




B HOURS 


Hours to 23 


6 




B MINS 


Minutes to 59 


6 




B SECS 


Seconds to 59 


3 




DAYOF_WEEK 


The day of the week (or if the day of week is not 
being broadcast) 


2 


OO2 


UTC OFFSET FR 
ACTION 


No additional offset 


OI2 


Add 15 minutes 


IO2 


Add 30 minutes 


II2 


Add 45 minutes 


4 


OO2 




Reserved 



The information element meaning of B_MONTH and DAYOF_WEEK values are specified in tables 7.70 and 7.71. 



7.2.19.4.1 



Broadcast Local Time - Month (B_MONTH) 



Table 7.70: B MONTH information element 



Information 
element 


Length 


Value 


Remark 


B_MONTH 


4 


OOOO2 


<Month not broadcast> 


0001 2 


January 


001 O2 


February 


00112 


March 


01002 


April 


01012 


May 


01102 


June 


01112 


July 


10002 


August 


10012 


September 


10102 


October 


10112 


November 


11002 


December 
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7.2.19.4.2 Broadcast Local Time - Day of Week (DAYSOF_WEEK) 

Table 7.71 : DAYSOF WEEK information element 



Information 
element 


Length 


Value 


Remark 


DAYSOF_WEEK 


3 


OOO2 


<Days of Week not broadcast> 


OOI2 


Sunday 


01 O2 


Monday 


OII2 


Tuesday 


IOO2 


Wednesday 


IOI2 


Thursday 


IIO2 


Friday 


III2 


Saturday 



7.2.19.5 Broadcast Mass Registration (MassReg) 

Table 7.72: Mass Registration 



Information 
element 


Length 


Value 


Alias 


Remark 


Broadcast 
Parms 1 


5 


OOOO2 




Reserved 


4 






Reg Window 


5 






Aloha IVIask 


Broadcast 
Parms 2 


24 






NULL or IVIS Individual Address 



7.2.19.5.1 



Reg_Window 



Table 7.73: Reg_Window 



Information 
element 


Length 


Value 


Treg_Window 


Remark 


Reg_Window 


4 







<Cancel Mass Registration> 


1 


.5 


Values in Seconds 


2 


1 


3 


2 


4 


5 


5 


10 


6 


20 


7 


30 


8 


100 


9 


300 


10 


1 000 


11 


3 000 


12 


10 000 


13 


30 000 


14 


100 000 


15 


200 000 
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7.2.1 9.6 Broadcast Adjacent Site information 

Table 7.74: Broadcast Adjacent Site information 



Information 
element 


Length 


Value 


Alias 


Remark 


Broadcast 
Parms 1 


14 






Most significant 14 bits of the C_SYScode 


Broadcast 
Parms 2 


1 






Active Connection 


23 






Reserved 



7.2.1 9.7 CdefParms absolute frequency relationship 

Table 7.75: CdefParms information element Definition 



CdefParms 


Information element Length Value Alias Remark 


CdefParms 


Cdeftype=00002 


Logical Physical 
Channel Number 


12 




CHAN 




Absolute transmitter 
frequency - integer MHz 


10 




TXMHz 


Absolute transmitter frequency - 
integer MHz 


Absolute transmitter 
frequency 


13 




TXKHz 


Part transmitter MHz in 125 Hz 
steps 


Absolute receiver 
frequency - integer MHz 


10 




RXMHz 


Absolute transmitter frequency - 
integer MHz 


Absolute receiver 
frequency 


13 




RXKHz 


Part receiver MHz in 125 Hz 
steps 




CdefParms 


Cdeftype=000l2to 
IIII2 




58 


Reserved 



The mechanism for calculating the absolute frequency is defined in annex C. 

7.2.20 Individual/Group (IG) 

Table 7.76: IG information element Definition 



Information 
element 


Length 


Value 


Alias 


Remark 


IG 


1 


O2 


G/l 


The Target Address information element in the 
PDU represents an individual MS address 


I2 


The Target Address information element in the 
PDU represents a talkgroup 
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7.2.21 Protect Kind 



Table 7.77: Protect Kind information element Definition 



Information 
element 


Length 


Value 


Alias 


Remark 


Protect_Kind 


3 


OOO2 


DIS_PTT 


Disable Target MS or Talkgroup 
transmission 


OOI2 


EN_PTT 


Enable Target MS or Talkgroup transmission 


01 O2 


ILLEGALLY_PARKED 


Clear down from the payload channel, MS 
whose address does not match Source or 
Target Address 


OII2 




Reserved 


IOO2 




Reserved 


IOI2 




Reserved 


IIO2 




Reserved 


III2 




Reserved 



7.2.22 Maint Kind 



Table 7.78: Maint Kind information element Definition 



Information 
element 


Length 


Value 


Alias 


Remark 


Maint_Kind 


3 


OOO2 


DISCON 


Disconnect. End of payload channel use 


OOI2 




Reserved 


01 O2 




Reserved 


OII2 




Reserved 


IOO2 




Reserved 


IOI2 




Reserved 


IIO2 




Reserved 


III2 




Reserved 



7.2.23 Response expected (A) 



Table 7.79: A information element Definition 



Information 
element 


Length 


Value 


Alias 


Remark 


A 


1 


O2 




Response not expected 


I2 




Response expected 
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7.2.24 Format 



Table 7.80: Format information element 



Information 
element 


Length 


Value 


Remark 


Format 


4 


OOOO2 


header for UDT 


0001 2 


Reserved 


001 O2 


Reserved 


00112 


Reserved 


01002 


Reserved 


01012 


Reserved 


01102 


Reserved 


01112 


Reserved 


10002 


Reserved 


10012 


Reserved 


10102 


Reserved 


10112 


Reserved 


11002 


Reserved 


11012 


Reserved 


11102 


Reserved 


11112 


Reserved 



7.2.25 Service Access Point (SAP) 



Table 7.81 : SAP information element 



Information 
element 


Length 


Value 


Remark 


SAP 


4 


OOOO2 


UDT 


0001 2 


See TS 102 361-1 [5] 


001 O2 


See TS 102 361-1 [5] 


00112 


See TS 102 361-1 [5] 


01002 


See TS 102 361-1 [5] 


01012 


See TS 102 361-1 [5] 


01102 


See TS 102 361-1 [5] 


01112 


See TS 102 361-1 [5] 


10002 


See TS 102 361-1 [5] 


10012 


See TS 102 361-1 [5] 


10102 


See TS 102 361-1 [5] 


10112 


See TS 102 361-1 [5] 


11002 


See TS 102 361-1 [5] 


11012 


See TS 102 361-1 [5] 


11102 


See TS 102 361-1 [5] 


11112 


See TS 102 361-1 [5] 
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7.2.26 Pad Nibble (PN) 

The PN information element specifies the number of pad nibbles which have been appended to the data to form an 
integer number of blocks. The number of pad nibbles for each of the UDT data formats is specified in annex B. 

Table 7.82: Pad Nibble 



Information element 


Length 


Value 


Remark 


Pad Nibble 


5 


Value 


Number of pad nibbles appended to the data 



7.2.27 UDT Format 

Specifies the format of the user or system data carried in UDTs for the UDT mechanism. 

Table 7.83: UDT Format information element 



Information 
element 


Length 


Value 


Remark 


UDT Format 


4 


OOOO2 


Binary 


0001 2 


MS Address 


001 O2 


4 bit BCD 


00112 


ISO 7 bit character set (ISO/IEC 646 [11]) 


01002 


ISO 8 bit character set (ISO/IEC 8859 [12]) 


01012 


NMEA location coded (lEC 61 1 62-1 [8]) 


01102 


IP address 


01112 


16 bit Unicode characters 


10002 


Custom Coded (manufacturer specific) 


10012 


Custom Coded (manufacturer specific) 


10102 


Reserved 


10112 


Reserved 


11002 


Reserved 


11012 


Reserved 


11102 


Reserved 


11112 


Reserved 



7.2.28 Offset 

On the outbound channel, specifies if the payload channel shall use offset or aligned timing. 

Table 7.84: Offset information element 



Information 
element 


Length 


Value 


Remark 


Offset 


1 


O2 


The payload channel shall use aligned timing 


I2 


The payload channel shall use offset timing 
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7.2.29 Protect Flag (PF) 

The Protect Flag is described in table 7.85. 



Table 7.85: Protect Flag 



Information element 


Length 


Value 


Remark 


Protect Flag (PF) 


1 


O2 


Defined in TS 102 361-1 Air Interface 



7.2.30 Privacy 

Privacy is described in table 7.86. 



Table 7.86: Privacy 



Information element 


Length 


Value 


Remark 


Privacy 


1 


02 


Defined in TS 102 361-1 Air Interface 
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Annex A (normative): 

Timers, constants levels and addresses 

This annex lists the timers and constants in a DMR MS. 

Where indicated, a value should be chosen from within the specified range. For other timers and constants, a default 
value may be specified and the value of these timers and constants shall be configurable within the DMR entity (MS, 
BSorTS). 



A.1 Layers timers 



Table A.1 : Layer 3 Timers 



Mnemonic 


Value 


Description 


Trand TC 


2 to 60 seconds 


Timeout for IVIS attempting Random Access 


T_Nosig 


1 to 15 seconds 


Timeout for entering hunting procedures if no TSCC is 
received 


T_EMERG_TIMER 


1 to 510 


Emergency Timer in steps of 30 seconds 
(e.g. 1 = 30 seconds, 2 = 60 seconds, etc.) 


511 


Emergency Timer is Infinity 


T_PACKET_TIMER 


1 to 30 


Packet Timer in steps of 5 seconds 


31 


Packet Timer is Infinity 


T_MS-MS_TIMER 


1 to 4 094 


IVIS to IVIS Timer in steps of 10 seconds 
(e.g. 1=10 seconds, 2 = 20 seconds, etc.) 


4 095 


MS to MS Timer is Infinity 


T_MS-LINE_TIMER 


1 to 4 094 


MS-Line Timer in steps of 10 seconds 
(e.g. 1 = 10 seconds, 2 = 20 seconds, etc.) 


4 095 


MS-Line Timer is Infinity 


TP_Timer 


4 to 60 seconds 


Timeout for a calling MS waiting for a call that requires a 
payload channel 


TNP_Timer 


2 to 20 seconds 


Timeout for a calling MS waiting for a call that does not 
require a payload channel 


T_Awake 


0.1 to 60 seconds 


Time MS stays awake after receiving a PDU (in steps of 
0,1 seconds) 


TV Hangtime 


1 to 60 seconds 


Payload Voice Hangtime timer 


TV Item 


1 to 60 seconds 


Payload Voice Maximum Item Timer 


TV Inactive 


to 20 seconds 


Payload Voice Inactivity Timer 


TD Inactive 


to 20 seconds 


Payload Data inactivity Timer 


TD Item 


1 to 60 seconds 


Payload Packet Data Maximum Item Timer 


T Pending 


2 to 60 seconds 


Timeout for called MS after receiving AHOY 


T dereg 


0,2 to 2 seconds 


Timer to de-register before abandon in 0,1 second steps 


T_BS_lnactive 


1 to 300 seconds 


Timer to hibernate if no inbound activity on an unregulated 
TSCC 


T_DENREG 





The denied registration timer is inactive 


1 to 1 000 


Denied registration lifetime in steps of 10 seconds 
(e.g. 1=10 seconds, 2 = 20 seconds, etc.) 
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A.2 Layer 3 constants 



Table A.2: Layer 3 Constants 



Mnemonic 


Value 


Description 


NDefault NW 


5 


NRand Wait at MS switch on 


NRand_NR 


6 


Number of random access attempts for a normal and high 
priority service 


NRand_NE 


10 


Number of random access attempts for a emergency priority 
service 


N_Maint 


4 


Number of P_MAINT PDUs transmitted by an MS to clear 
down the payload channel 


Nmax Ch 


50 


Minimum Number of channels in Short Hunt List 


Low Comp Ch 


1 to 4 095 


Lowest logical channel in use by the network 


High_Comp_Ch 


Low Comp Ch 
to 4 095 


Highest logical channel in use by the network 


Comp Flag 


True/False 


Suppress Comprehensive Hunt (see annex D) 


NSYSerr 


1 to 3 


Number of C_SYScodes received that differ from the value 
verified 


DMRLA 


Oto10 


Length of SYS AREA information field from the C SYScode 


VOTE_BLK 


2 to 10 


Number of TDMA frames that random access activity is 
withdrawn after a Vote Now Advice 



A.3 Layer 3 levels 



Table A.3: Layer 3 signal levels 



Mnemonic 


Value 


Description 


L_Upper_SHort 


Units and values 
are manufacturer 
specific 


The threshold of signal quality above which will be sampled 
first in a short hunt 


L_Lower_SHort 


The threshold of signal quality below which the MS shall be 
unable to become active 


L_Squelch 


Signal level (or equivalent) below which physical channels 
are to be rejected because the received signal quality is 
inadequate 


L_Power_Hi 


Units and values 

are manufacturer 

specific 


Lower limit of signal strength sample received by the TS for 
power control 


L_Power_Low 


Upper limit of signal strength sample received by the TS for 
power control 
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A.4 Tier III Gateways/Identifiers 



Table A.4: Gateways / Identifiers 



DMRID 


Alias 


Remark 


FFFECO^e 


PSTNI 


Gateway address for services to the PSTN using payload aligned timing 


FFFEC1,6 


PABXI 


Gateway address for services to the PABX using payload aligned timing 


FFFEC2,6 


LINEI 


Address for services to a Line Gateway using payload aligned timing 


FFFEC3i6 


IPI 


Address for services to an IP Gateway using payload aligned timing 


FFFEC4,3 


SUPLI 


Address used to identify an supplementary data service 


FFFEC5i6 


SDMI 


Address used to identify a short data service 


FFFEC616 


REGI 


Address used to identify a registration service 


FFFEC7,3 


MSI 


Address used to identify the totality of individual MS address space 


FFFEC816 


TGI 


Address used to identify the totality of talkgroup address space 


FFFEC9i6 


DIVERTI 


Address used to identify a call diversion cancellation 


FFFECA^e 


TSI 


Address of the TS 


FFFECB^e 


DISPATI 


Address of the system dispatcher using payload aligned timing 


FFFECC16 


STUNI 


MS Stun/Unstun Identifier 


FFFECD^e 


AUTHI 


Authentication Identifier 


FFFECE,6 


GPI 


Talkgroup Identifier 


FFFECF,3 


KILLI 


MS KILL Identifier 


FFFEDO16 


PSTNDI 


Gateway address for services to the PSTN using payload offset timing 


FFFED1,6 


PABXDI 


Gateway address for services to the PABX using payload offset timing 


FFFED2,6 


LINEDI 


Address for services to a Line Gateway using payload offset timing 


FFFEDS^e 


DISPATDI 


Address of the system dispatcher using payload offset timing 


FFFED4,6 


ALLMSI 


The totality of all individual MS and talkgroups 
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Annex B (normative): 
Opcode Reference Lists 

B.1 CSBK/IVIBC/UDT Opcode List 

Table B.I : CSBK/MBC/UDT Opcode List 



OPCODE 


OPCODE2 


Description 


Alias 






Channel Grant 




48 


1 1 OOOO2 


Private Voice Ciiannei Grant 


PV_GRANT 


49 


11 0001 2 


Talkgroup Voice Ciiannei Grant 


TV_GRANT 


50 


11 001 O2 


Private Broadcast Voice Ciiannei Grant 


PBV_GRANT 


51 


11 001 12 


Private Data Ciiannei Grant 


PD_GRANT 


52 


11 01002 


Taikgroup Data Ciiannei Grant 


TD_GRANT 






IVIove 




57 


11 10002 


iVIove PDUs 


C_MOVE 






Aloha 




25 


01 IOOI2 


Aiolia PDUs for tiie random access protocoi 


C_ALOHA 






Announcements 




40 


1010002 


Announcement PDUs tliat siiaii not demand a response. 

Announce/Witiidraw TSCC 

Specify caii Timers 

Vote now advice 

Announce iocai time 

Announce a iogical piiysicai channel 
reiationsliip 


C_BCAST 


46 


1011102 


Clear 


P_CLEAR 


47 


1011112 


Protect 


P_PROTECT 






Ahoy PDUs 




28 


01 IIOO2 


Ahoy - enquiry that demands a response TSCC 


C AHOY 
P AHOY 






Acknowledgements 




32 


1000002 


Acknowledgement response outbound TSCC 


C_ACKD 


33 


10 0001 2 


Acknowledgement response inbound TSCC 


C_ACKU 


34 


1000102 


Acknowledgement response outbound Payload 


P_ACKD 


35 


1000112 


Acknowledgement response inbound Payload 


P_ACKU 






UDT Header 




26 


01 IOIO2 


Unified Data Transport outbound Header 


C_UDTHD 


27 


01 IOII2 


Unified Data Transport inbound Header 


C_UDTHU 






Random Access Service Request 




31 


01 IIII2 


Random Access Service Request 


C_RAND 






Ackvitation 




30 


01 IIIO2 


Ackvitation PDU 


C_ACKVIT 






Maintenance PDU 




42 


1010102 


IVIaintenance 


P_MAINT 
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B.2 Short Link Control Opcode List 



Table B.2: SLCO Opcode List 



SLCO 


Description 


Alias 


001 O2 


System Parameters and slot counter 


SYS_Parm 



B.3 Appended Data Information Elements 

A UDT PDU may carry information elements. A UDT header PDU carries the source and destination addresses and a 
UDT Format information element that prescribes the format of the appended data. 

The UDT Header is the first block of a multi-block UDT. The number of blocks making up the multi-block UDT is 
specified by the AB information element. All PDUs are specified in clause 7.2. 



UDT HEADER 




7 6 


5 4 


3 2 10 


Octet OlH A 


RSVD 


FORMAT 


Octet 1 


SAP 


UDT FORMAT 


Octet 2 


TARGET ADDRESS OR 
(5ATEWAy(24) 


Octet 3 


Octet 4 


Octet 5 


SOURCE ADDRESS OR 
(5ATEWAy(24) 


Octet 6 


Octet 7 


Octet 8 


PAD NIBBLE UAB 


Octet 9B3pF 


OPCODE 



HEADER BLOCK 



Figure B.1: UDT header Block 



B.3.1 Appended Data Binary Format 



Appended data is binary coded. Up to four appended UDT blocks may be concatenated with the UDT header to form a 
multi-block UDT PDU. Up to 367 bits may be transported. For binary format transport the Pad Nibble information 
element in the UDT header is set to OOOO2. If variable length binary data is being transported, the last bit of the user 

data may identified as follows: 

• A O2 is appended to the user data and the remaining bits to fill a UDT block are set to I2. The UDT header and 
appended blocks are then transmitted. 

• The receiver may identify the end of user data by counting backwards until the first O2 is reached. That point is 
one bit past the user data. 
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APPENbEb bATA UbTF=00002 




7|6|5|4|3|2|l|0 


Octet 


Binary(80) 


Octet 1 


Octet 2 


Octet 3 


Octet 4 


Octet 5 


Octet 6 


Octet 7 


Octet 8 


Octet 9 



APPENbEb MBC #1 



Figure B.2: Unified Data Transport Format (Binary) 1 bit to 79 bits 

One appended UDT may transport from 1 bit to 79 bits (because the last user bit must be identified by adding a O2 to the 
end of the user data). 



APPENDED DATA UDTF=00002 




7|6|5|4|3|2|l|0 


Octet 


Binary(96) 


Octet 1 


Octet 2 


Octet 3 


Octet 4 


Octet 5 


Octet 6 


Octet 7 


Octet 8 


Octet 9 


Octet 10 


Octet 11 



APPENDED DATA UDTF=00002 




7|6|5|4|3|2|l|0 


Octet 


Binary(80) 


Octet 1 


Octet 2 


Octet 3 


Octet 4 


Octet 5 


Octet 6 


Octet 7 


Octet 8 


Octet 9 



APPENDED MBC #2 



APPENDED MBC #1 



Figure B.3: Unified Data Transport Format (Binary) 80 bits to 175 bits 

Two appended UDTs may transport from 80 bits to (96 + 79) = 175 bits. 



APPENDED DATA UDTF=00002 




76543210 


Octet 


Binary(96) 


Octet 1 


Octet 2 


Octet 3 


Octet 4 


Octet 5 


Octet 6 


Octet 7 


Octet 8 


Octet 9 


Octet 10 


Octet 11 




APPENDED MBC #1 



APPENDED DATA UDTF=00002 




76543210 


Octet 


Biiiary(96) 


Octet 1 


Octet 2 


Octet 3 


Octet 4 


Octet 5 


Octet 6 


Octet 7 


Octet 8 


Octet 9 


Octet 10 


Octet 11 




APPENDED MBC #2 



APPENDED DATA UDTF-OOOO2 




76543210 


Octet 


Biiiary(80) 


Octet 1 


Octet 2 


Octet 3 


Octet 4 


Octet 5 


Octet 6 


Octet 7 


Octet 8 


Octet 9 




APPENDED MBC #3 



Figure B.4: Unified Data Transport Format (Binary) 176 bits to 271 bits 

Three appended UDTs may transport from 176 bits to (96 + 96 + 79) = 271 bits. 



ETSI 



195 



ETSI TS 102 361-4 V1.3.1 (2010-06) 



APPENDED DATA UDTF=00002 




7|6|5|4|3|2|1|0 


Octet 


Binary(96) 


Octet 1 


Octet 2 


Octets 


Octet 4 


Octet 5 


Octet 6 


Octet/ 


Octets 


Octet 9 


Octet 10 


Octet 11 




APPENDED MBC #1 



APPENDED DATA UDTF=00002 




7|6|5|4|3|2|1|0 


Octet 


Binary(96) 


Octet 1 


Octet 2 


Octet 3 


Octet 4 


Octet 5 


Octet 6 


Octet 7 


Octet 8 


Octet 9 


Octet 10 


Octet 11 




APPENDED MBC #2 



APPENDED DATA UDTF=00002 




7|6|5|4|3|2|1|0 


Octet 


Binary(96) 


Octet 1 


Octet 2 


Octet 3 


Octet 4 


Octet 5 


Octet 6 


Octet 7 


Octets 


Octet 9 


Octet 10 


Octet 11 




APPENDED MBC #3 



APPENDED DATA UDTF=00002 




7|6|5|4|3|2|1|0 


Octet 


Binary(SO) 


Octet 1 


Octet 2 


Octet 3 


Octet 4 


Octet 5 


Octet 6 


Octet 7 


Octets 


Octet 9 




APPENDED MBC #4 



Figure B.5: Unified Data Transport Format (Binary) 272 bits to 367 bits 

Four appended UDTs may transport from 272 bits to (96 + 96 + 96 + 79) = 367 bits. 

B.3.2 Appended Data Addressing Format 

Appended data is 24 bit address coded. One appended data UDTs may be concatenated with a UDT appended data 
header to form a multi-block UDT PDU. Up to three addresses may be transported. 



APPENDED DATA UDTF=000l2 




7 1 6 


5 1 4 1 3 1 2 1 1 1 


Octet 


RSVb 


CSBK Opcocle(6) 


Octet 1 


AbbRESSl(24) 


Octet 2 


Octet 3 


Octet 4 


AbbRESS2(24) 


Octet 5 


Octet 6 


Octet 7 


AbbRESS3(24) 


Octet 8 


Octet 9 







APPENDED MBC #1 



Figure B.6: Appended data Address Format 

Unused address information elements are filled with NULL. 

B.3.3 Appended Data BCD Format 

Appended data is BCD coded. Up to four appended data UDTs may be concatenated with UDT appended data header to 
form a multi-block UDT PDU. Up to 92 BCD digits may be transported. The Pad Nibble information element in the 
UDT header specifies the number of 4 bit nibbles (1 1 1 12) that have been padded to the user digits to completely fill a 
block. 

The number of user BCD digits and the corresponding value of AB and Pad Nibble is given by table B.3. 
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Table B.3: Relationship of user BCD digits, UAB and Pad Nibble information elements 



User 
BCD 
Digits 


UAB 


Pad Nibble 


1 





19 


2 





18 


3 





17 


4 





16 


5 





15 


6 





14 


7 





13 


8 





12 


9 





11 


10 





10 


11 





9 


12 





8 


13 





7 


14 





6 


15 





5 


16 





4 


17 





3 


18 





2 


19 





1 


20 








21 




23 


22 




22 


23 




21 


24 




20 


25 




19 


26 




18 


27 




17 


28 




16 


29 




15 


30 




14 


31 




13 



User 
BCD 
Digits 


UAB 


Pad Nibble 


32 




12 


33 




11 


34 




10 


35 




9 


36 




8 


37 




7 


38 




6 


39 




5 


40 




4 


41 




3 


42 




2 


43 




1 


44 







45 


2 


23 


46 


2 


22 


47 


2 


21 


48 


2 


20 


49 


2 


19 


50 


2 


18 


51 


2 


17 


52 


2 


16 


53 


2 


15 


54 


2 


14 


55 


2 


13 


56 


2 


12 


57 


2 


11 


58 


2 


10 


59 


2 


9 


60 


2 


8 


61 


2 


7 


62 


2 


6 



User 
BCD 
Digits 


UAB 


Pad Nibble 


63 


2 


5 


64 


2 


4 


65 


2 


3 


66 


2 


2 


67 


2 


1 


68 


2 





69 


3 


23 


70 


3 


22 


71 


3 


21 


72 


3 


20 


73 


3 


19 


74 


3 


18 


75 


3 


17 


76 


3 


16 


77 


3 


15 


78 


3 


14 


79 


3 


13 


80 


3 


12 


81 


3 


11 


82 


3 


10 


83 


3 


9 


84 


3 


8 


85 


3 


7 


86 


3 


6 


87 


3 


5 


88 


3 


4 


89 


3 


3 


90 


3 


2 


91 


3 


1 


92 


3 












APPENbEb bATA UbTF=00102 




7|6|5|4 


3|2|1|0 


Octet 


Digit(4) 


Digit(4) 


Octet 1 


Digit(4) 


Digit(4) 


Octet 2 


Digit(4) 


Digit(4) 


Octets 


Digit(4) 


Digit(4) 


Octet 4 


Diqit(4) 


Diqit(4) 


Octets 


Digit(4) 


Digit(4) 


Octet 6 


Digit(4) 


Digit(4) 


Octet? 


Digit(4) 


Digit(4) 


Octets 


Digit(4) 


Digit(4) 


Octet 9 


Digit(4) 


Digit(4) 



APPENbEb MBC #1 



Figure B.7: Unified Data Transport Format (BCD) 1 digit to 20 digits 
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APPENDED DATA UDTF=00102 




7|6|5|4 


3 1 2 1 1 1 


Octet 


Digit(4) 


Digit(4) 


Octet 1 


Digit(4) 


Digit(4) 


Octet 2 


Digit(4) 


Digit(4) 


Octet 3 


Digit(4) 


Digit(4) 


Octet 4 


Digit(4) 


Digit(4) 


Octet 5 


Digit(4) 


Digit(4) 


Octet 6 


Digit(4) 


Digit(4) 


Octet 7 


Digit(4) 


Digit(4) 


Octet 8 


Digit(4) 


Digit(4) 


Octet 9 


Digit(4) 


Digit(4) 


Octet 10 


Digit(4) 


Digit(4) 


Octet 11 


Digit(4) 


Digit(4) 




APPENDED mC #1 



APPENDED DATA UDTF=00102 




7|6|5|4 


3|2| 1 |0 


Octet 


Digit(4) 


Digit(4) 


Octet 1 


Digit(4) 


Digit(4) 


Octet 2 


Digit(4) 


Digit(4) 


Octet 3 


Digit(4) 


Digit(4) 


Octet 4 


Digit(4) 


Digit(4) 


Octet 5 


Digit(4) 


Digit(4) 


Octet 6 


Digit(4) 


Digit(4) 


Octet 7 


Digit(4) 


Digit(4) 


Octet 8 


Digit(4) 


Digit(4) 


Octet 9 


Digit(4) 


Digit(4) 




APPENDED MBC #2 



Figure B.8: Unified Data Transport Format (BCD) 21 digits to 44 digits 



APPENDED DATA UDTF=00102 




7|6|5|4 


3 1 2 1 1 1 


Octet 


Digit(4) 


Digit(4) 


Octet 1 


Digit(4) 


Digit(4) 


Octet 2 


Digit(4) 


Digit(4) 


Octet 3 


Digit(4) 


Digit(4) 


Octet 4 


Digit(4) 


Digit(4) 


Octet 5 


Digit(4) 


Digit(4) 


Octet 6 


Digit(4) 


Digit(4) 


Octet 7 


Digit(4) 


Digit(4) 


Octet 8 


Digit(4) 


Digit(4) 


Octet 9 


Digit(4) 


Digit(4) 


Octet 10 


Digit(4) 


Digit(4) 


Octet 11 


Digit(4) 


Digit(4) 




APPENDED MBC #1 



APPENDED DATA UDTF=00102 




7|6|5|4 


3 1 2 1 1 1 


Octet 


Digit(4) 


Digit(4) 


Octet 1 


Digit(4) 


Digit(4) 


Octet 2 


Digit(4) 


Digit(4) 


Octet 3 


Digit(4) 


Digit(4) 


Octet 4 


Digit(4) 


Digit(4) 


Octet 5 


Digit(4) 


Digit(4) 


Octet 6 


Digit(4) 


Digit(4) 


Octet 7 


Digit(4) 


Digit(4) 


Octet 8 


Digit(4) 


Digit(4) 


Octet 9 


Digit(4) 


Digit(4) 


Octet 10 


Digit(4) 


Digit(4) 


Octet 11 


Digit(4) 


Digit(4) 




APPENDED MBC #2 



APPENDED DATA UDTF=00102 




7 1 6 1 5 1 4 


3|2| 1 |0 


Octet 


Digit(4) 


Digit(4) 


Octet 1 


Digit(4) 


Digit(4) 


Octet 2 


Digit(4) 


Digit(4) 


Octet 3 


Digit(4) 


Digit(4) 


Octet 4 


Digit(4) 


Digit(4) 


Octet 5 


Digit(4) 


Digit(4) 


Octet 6 


Digit(4) 


Digit(4) 


Octet 7 


Digit(4) 


Digit(4) 


Octet 8 


Digit(4) 


Digit(4) 


Octet 9 


Digit(4) 


Digit(4) 




APPENDED MBC #3 



Figure B.9: Unified Data Transport Format (BCD) 45 digits to 65 digits 



APPENDED DATA UDTF=00102 




7|6|5|4 


3|2|1 |0 


Octet 


Digit(4) 


Digit(4) 


Octet 1 


Digit(4) 


Digit(4) 


Octet 2 


Digit(4) 


Digit(4) 


Octet 3 


Digit(4) 


Digit(4) 


Octet 4 


Digit(4) 


Digit(4) 


Octet 5 


Digit(4) 


Digit(4) 


Octet 6 


Digit(4) 


Digit(4) 


Octet 7 


Digit(4) 


Digit(4) 


Octet 8 


Digit(4) 


Digit(4) 


Octet 9 


Digit(4) 


Digit(4) 


Octet 10 


Digit(4) 


Digit(4) 


Octet 11 


Digit(4) 


Digit(4) 




APPENDED MBC #1 



APPENDED DATA UDTF=00102 




7 1 6 1 5 1 4 


3|2|1|0 


Octet 


Digit(4) 


Digit(4) 


Octet 1 


Digit(4) 


Digit(4) 


Octet 2 


Digit(4) 


Digit(4) 


Octet 3 


Digit(4) 


Digit(4) 


Octet 4 


Digit(4) 


Digit(4) 


Octet 5 


Digit(4) 


Digit(4) 


Octet 6 


Digit(4) 


Digit(4) 


Octet 7 


Digit(4) 


Digit(4) 


Octet 8 


Digit(4) 


Digit(4) 


Octet 9 


Digit(4) 


Digit(4) 


Octet 10 


Digit(4) 


Digit(4) 


Octet 11 


Digit(4) 


Digit(4) 




APPENDED MBC #2 



APPENDED DATA UDTF=00102 




7|6|5|4 


3 1 2 1 1 1 


Octet 


Digit(4) 


DigiK4) 


Octet 1 


Digit(4) 


DigiK4) 


Octet 2 


Digit(4) 


DigiK4) 


Octet 3 


Digit(4) 


DigiK4) 


Octet 4 


Digit(4) 


DigiK4) 


Octet 5 


Digit(4) 


DigiK4) 


Octet 6 


Digit(4) 


DigiK4) 


Octet 7 


Digit(4) 


DigiK4) 


Octet 8 


Digit(4) 


DigiK4) 


Octet 9 


Digit(4) 


DigiK4) 


Octet 10 


Digit(4) 


DigiK4) 


Octet 11 


Digit(4) 


DigiK4) 




APPENDED MBC #3 



APPENDED DATA UDTF=00102 




7 1 6 1 5 1 4 


3|2|1|0 


Octet 


Digit(4) 


Digit(4) 


Octet 1 


Digit(4) 


Digit(4) 


Octet 2 


Digit(4) 


Digit(4) 


Octet 3 


Digit(4) 


Digit(4) 


Octet 4 


Digit(4) 


Digit(4) 


Octet 5 


Digit(4) 


Digit(4) 


Octet 6 


Digit(4) 


Digit(4) 


Octet 7 


Digit(4) 


Digit(4) 


Octet 8 


Digit(4) 


Digit(4) 


Octet 9 


Digit(4) 


Digit(4) 




APPENDED MBC #4 



Figure B.10: Unified Data Transport Format (BCD) 66 digits to 92 digits 

B.3.4 Appended Data ISO 7 bit character set Format 

Appended data is coded ISO 7 bit character set (ISO/IEC 646 [11]). Up to four appended data UDTs may be 
concatenated with a UDT appended data header to form a muki-block UDT PDU. Up to 52 ISO 7 bit characters may be 
transported. The Pad Nibble information element in the UDT header specifies the number of 4 bit nibbles (1 1 1 12) that 
have been padded to the 7 bit character symbols to completely fill a block. An exact fit of pad nibbles is not always 
possible but there is sufficient indication to unambiguously specify the number of text symbols. 

The number of user 7 bit character symbols, and the corresponding value of UAB and Pad Nibble is given by table B.4. 
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Table B.4: Relationship of ISO 7 bit symbols, UAB and Pad Nibble information elements 



User 7 bit 
Symbols 


UAB 


Pad Nibble 


1 





18 


2 





16 


3 





14 


4 





13 


5 





11 


6 





9 


7 





7 


8 





6 


9 





4 


10 





2 


11 








12 




23 


13 




21 


14 




19 


15 




17 


16 




16 


17 




14 


18 




12 



User 7 bit 
Symbols 


UAB 


Pad Nibble 


19 




10 


20 




9 


21 




7 


22 




5 


23 




3 


24 




2 


25 







26 


2 


22 


27 


2 


20 


28 


2 


19 


29 


2 


17 


30 


2 


15 


31 


2 


13 


32 


2 


12 


33 


2 


10 


34 


2 


8 


35 


2 


6 


36 


2 


5 



User 7 bit 
Symbols 


UAB 


Pad Nibble 


37 


2 


3 


38 


2 


1 


39 


3 


23 


40 


3 


22 


41 


3 


20 


42 


3 


18 


43 


3 


16 


44 


3 


15 


45 


3 


13 


46 


3 


11 


47 


3 


9 


48 


3 


8 


49 


3 


6 


50 


3 


4 


51 


3 


2 


52 


3 


1 















APPENDED DATA UDTF=001l2 




7|6|5|4|3|2|1 





Oc-tetO 


Digit(7) 




Octet 1 


Digit(7) 1 


Octet 2 


Digit(7) 1 


Octets 


Digit(7) 1 DigiK7) 


Octet 4 


1 Digit(7)- 


Octets 


1 DigiK7) 


Octet 6 


1 DigiK7) 


Octet? 


Digit(7) 1 


Octets 


Digit(7) 


— 


Octet 9 


Digit(7) 1 1 


1 1 



APPENDED MBC #1 



Figure B.11 : Unified Data Transport Format (ISO 7 bit) 1 text symbol to 11 text symbols 



APPENDED DATA UDTF=001l2 




7|6|5|4|3|2| 1 





Octet 


Digit(7) 




Octet 1 


Digit(7) 1 


Octet 2 


Digit(7) 1 


Octet 3 


Digit(7) 1 Digit(7) 


Octet 4 


1 Digit(7)- 


Octet 5 


1 C)igit(7) 


Octet 6 


1 C)igit(7) 


Octet 7 


Digit(7) 1 


Octet 8 


Digit(7) 1 -- 


Octet 9 


Digit(7) 1 


Octet 10 


Digit(7) 1 Digit(7) 


Octet 11 


1 Digit(7)— 




APPENDED MBC #1 



APPENDED DATA UDTF=001l2 




7 1 6 


5|4|3|2| 1 |0 


Octet 




Digit(7) 


Octet 1 


1 C)igit(7) 


Octet 2 


Digit(7) \ 


Octet 3 


Digit(7) 1 — - 


Octet 4 


Digit(7) 1 


Octet 5 


Digit(7) | Digit(7) 


Octet 6 


1 Digit(7)- 


Octet 7 


1 C)igit(7) 


Octet 8 


Digit(7) 


Octet 9 


Digit(7) 1 1 




APPENDED MBC #2 



Figure B.I 2: Unified Data Transport Format (ISO 7 bit) 12 text symbols to 25 text symbols 
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APPENDED DATA UDTF=001l2 




7|6|5|4|3|2| 1 





Octet 


Digit(7) 




Octet 1 


Digit(7) 1 


Octet 2 


Digit(7) 1 


Octets 


Digit(7) 1 Digit(7) 


Octet 4 


1 Digit(7)- 


Octets 


1 (^igi1(7) 


Octet 6 


1 (^igiK7) 


Octet? 


(^igit(7) \ 


Octets 


Digit(7) 1 -- 


Octet 9 


Digit(7) 1 


Octet 10 


Digit(7) 1 Digit(7) 


Octet 11 


1 Digit(7)- 




APPENDED MBC #1 



APPENDED DATA UDTF=001l2 




7 1 6 


5 1 4 1 3 1 2 1 1 1 


Octet 




Digit(7) 


Octet 1 


1 (^igi1(7) 


Octet 2 


(^igit(7) L 


Octets 


Digit(7) 1 -- 


Octet 4 


Digit(7) 1 


Octets 


Digit(7) 1 Digit(7) 


Octet 6 


1 Digit(7)- 


Octet 7 


1 (^igi1(7) 


Octets 


1 (^igiK7) 


Octet 9 


Digit(7) 1 


Octet 10 


Digit(7) 1 


Octet 11 


Digit(7) 




APPENDED MBC #2 



APPENDED DATA UDTF=001l2 




7|6|S|4 


3|2| 1 |0 


Octet 


Digit(7) 


Digit(7) 


Octet 1 


1 Digit(7)- 


Octet 2 


1 (^igi1(7) 


Octets 


1 (^igiK7) 


Octet 4 


Digit(7) 1 


Octets 


Digit(7) 1 -- 


Octet 6 


Digit(7) 1 


Octet 7 


Digit(7) 1 Digit(7) 


Octets 




Digit(7)- 


Octet 9 


h 


1 |l|l|l |l 



APPENDED MBC #3 



Figure B.13: Unified Data Transport Format (ISO 7 bit) 26 text symbols to 38 text symbols 



APPENDED DATA UDTF=001l2 




7|6|5|4|3|2|1 





Octet 


Digit(7) 




Octet 1 


Digit(7) 1 


Octet 2 


Digit(7) 


Octet 3 


Digit(7) 1 Digit(7) 


Octet 4 


Digit(7)— 


Octet 5 


1 Digit(7) 


Octet 6 


1 bigit(7) 


Octet 7 


Digit(7) 1 


Octet 8 


Digit(7) 1 -- 


Octet 9 


Digit(7) 1 


Octet 10 


Digit(7) 1 Digit(7) 


Octet 11 


1 Digit(7)- 




APPENDED MBC #1 



APPENDED DATA UDTF=001l2 




7|6 


5 1 4 1 3 1 2 1 1 1 


Octet 




Digit(7) 


Octet 1 


1 Digit(7) 


Octet 2 


bigit(7) L 


Octet 3 


Digit(7) 1 -- 


Octet 4 


Digit(7) 1 


Octet 5 


Digit(7) 1 Digit(7) 


Octet 6 


1 Digit(7)— 


Octet 7 


1 bigit(7) 


Octet 8 


1 bigit(7) 


Octet 9 


Digit(7) 1 


Octet 10 


Digit(7) 1 


Octet 11 


Digit(7) 1 




APPENDED MBC #2 



APPENDED DATA UDTF=001l2 




7|6|5|4 


3 1 2 1 1 1 


Octet 


Digit(7) 


Digit(7) 


Octet 1 


1 Digit(7)— 


Octet 2 


1 bigit(7) 


Octet 3 


1 Digit(7) 


Octet 4 


Digit(7) 1 


Octet 5 


Digit(7) 1 


Octet 6 


Digit(7) 1 


Octet 7 


Digit(7) Digit(7) 


Octet 8 


1 Digit(7)- 


Octet 9 


1 bigit(7) 


Octet 10 


1 bigit(7) 


Octet 11 


Digit(7) 1 




APPENDED MBC #3 



APPENDED DATA UDTF=001l2 




7|6|5|4|3|2|1|0 


Octet 


Digit(7) 1 — - 


Octet 1 


Digit(7) 1 


Octet 2 


Digit(7) Digit(7) 


Octet 3 


1 Digit(7)- 


Octet 4 


1 bigit(7) 


Octet 5 


1 Digit(7) 


Octet 6 


Digit(7) 1 


Octet 7 


Digit(7) 1 


Octet 8 


Digit(7) 


Octet 9 


Digit(7) 1111 




APPENDED MBC #4 



Figure B.14: Unified Data Transport Format (ISO 7 bit) 39 text symbols to 52 text symbols 

B.3.5 Appended Data ISO 8 bit Character Format 

Appended data is coded ISO 8 bit character format (ISO/IEC 8859 [12]). Up to four appended data UDTs may be 
concatenated with UDT appended data header to form a multi-block UDT PDU. Up to 46 ISO 8 bit characters may be 
transported. The Pad Nibble information element in the UDT header specifies the number of 4 bit nibbles (1 1 1 12) that 
have been padded to the Character symbols to completely fill a block. 

The number of user 8 bit characters, and the corresponding value of UAB and Pad Nibble is given by table B.5. 
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Table B.5: Relationship of 8 bit character symbols, UAB and Pad Nibble information elements 



User 
Character 
Symbols 


UAB 


Pad Nibble 


1 





18 


2 





16 


3 





14 


4 





12 


5 





10 


6 





8 


7 





6 


8 





4 


9 





2 


10 








11 




22 


12 




20 


13 




18 


14 




16 


15 




14 


16 




12 



User 
Character 
Symbols 


UAB 


Pad Nibble 


17 




10 


18 




8 


19 




6 


20 




4 


21 




2 


22 







23 


2 


22 


24 


2 


20 


25 


2 


18 


26 


2 


16 


27 


2 


14 


28 


2 


12 


29 


2 


10 


30 


2 


8 


31 


2 


6 


32 


2 


4 



User 
Character 
Symbols 


UAB 


Pad Nibble 


33 


2 


2 


34 


2 





35 


3 


22 


36 


3 


20 


37 


3 


18 


38 


3 


16 


39 


3 


14 


40 


3 


12 


41 


3 


10 


42 


3 


8 


43 


3 


6 


44 


3 


4 


45 


3 


2 


46 


3 


















APPEN bEb bATA UbTF=01002 



Octet 



Octet 1 



Octet 2 



Octet 3 



Octet 4 



Octet 5 



Octet 6 



Octet 7 



Octet 8 



Octet 9 



76543210 



Digit(8) 



Digit(8) 



Digit(8) 



Digit(8) 



Digit(8) 



Digit(8) 



Digit(8) 



Digit(8) 



Digit(8) 



Digit(8) 



APPENbEb MBC #1 



Figure B.15: Unified Data Transport Format (8 bit character) 1 character symbol 

to 10 character symbols 



APPENDED DATA UDTF=01002 




7|6|5|4|3|2|l 





Octet 


Digit(8) 


Octet 1 


Digit(8) 


Octet 2 


Digit(8) 


Octets 


Digit(8) 


Octet 4 


Digit(8) 


Octets 


Digit(8) 


Octet 6 


Digit(8) 


Octet 7 


Digit(8) 


Octets 


Digit(8) 


Octet 9 


Digit(8) 


Octet 10 


Digit(8) 


Octet 11 


Digit(8) 




APPENDED MBC #1 



APPENDED DATA UDTF=01002 




7|6|5|4|3|2|l 





Octet 


Digit(8) 


Octet 1 


Digit(8) 


Octet 2 


Digit(8) 


Octets 


Digit(8) 


Octet 4 


Digit(8) 


Octets 


Digit(8) 


Octet 6 


Digit(8) 


Octet 7 


Digit(8) 


Octet 8 


Digit(8) 


Octet 9 


Digit(8) 




APPENDED MBC #2 



Figure B.I 6: Unified Data Transport Format (8 bit character) 11 character symbols 

to 22 character symbols 
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APPENDED DATA UDTF=01002 




7|6|5|4|3|2|1|0 


Octet 


Digit(8) 


Octet 1 


Digit(8) 


Octet 2 


Digit(8) 


Octet 3 


Digit(8) 


Octet 4 


Digit(8) 


Octet 5 


Digit(8) 


Octet 6 


Digit(8) 


Octet 7 


Digit(8) 


Octet 8 


Digit(8) 


Octet 9 


Digit(8) 


Octet 10 


Digit(8) 


Octet 11 


Digit(8) 




APPENDED MBC #1 



APPENDED DATA UDTF=01002 




7|6|5|4|3|2|1|0 


Octet 


Digit(8) 


Octet 1 


Digit(8) 


Octet 2 


Digit(8) 


Octet 3 


Digit(8) 


Octet 4 


Digit(8) 


Octet 5 


Digit(8) 


Octet 6 


Digit(8) 


Octet? 


Digit(8) 


Octet 8 


Digit(8) 


Octet 9 


Digit(8) 


Octet 10 


Digit(8) 


Octet 11 


Digit(8) 




APPENDED MBC #2 



APPENDED DATA UDTF=01002 




7|6|5|4|3|2|1|0 


Octet 


Digit(8) 


Octet 1 


Digit(8) 


Octet 2 


Digit(8) 


Octet 3 


Digit(8) 


Octet 4 


Digit(8) 


Octet 5 


Digit(8) 


Octet 6 


Digit(8) 


Octet 7 


Digit(8) 


Octet 8 


Digit(8) 


Octet 9 


Digit(8) 




APPENDED MBC #3 



Figure B.17: Unified Data Transport Format (8 bit character) 23 character symbols 

to 34 character symbols 



APPENDED DATA UDTF=01002 




7|6|5|4|3|2|l|0 


Octet 


Digit(8) 


Octet 1 


Digit(8) 


Octet 2 


Digit(8) 


Octet 3 


Digit(8) 


Octet 4 


Digit(8) 


Octet 5 


Digit(8) 


Octet 6 


Digit(8) 


Octet 7 


Digit(8) 


Octet 8 


Digit(8) 


Octet 9 


Digit(8) 


Octet 10 


Digit(8) 


Octet 11 


Digit(8) 




APPENDED MBC #1 



APPENDED DATA UDTF=01002 




7|6|5|4|3|2|l|0 


Oc-tetO 


Digit(8) 


Octet 1 


Digit(8) 


Oc-tet2 


Digit(8) 


Oc-tet3 


Digit(8) 


Oc-tet4 


Digit(8) 


Oc-tet5 


Digit(8) 


Oc-tet6 


Digit(8) 


Oc-tet7 


Digit(8) 


Oc-tet8 


Digit(8) 


Oc-tet9 


Digit(8) 


Oc-tet 10 


Digit(8) 


Octet 11 


Digit(8) 




APPENDED MBC #2 



APPENDED DATA UDTF=01002 




7|6|5|4|3|2|l|0 


Octet 


Digit(8) 


Octet 1 


Digit(8) 


Octet 2 


Digit(8) 


Octet 3 


Digit(8) 


Octet 4 


Digit(8) 


Octet 5 


Digit(8) 


Octet 6 


Digit(8) 


Octet 7 


Digit(8) 


Octet 8 


Digit(8) 


Octet 9 


Digit(8) 


Oc-tet 10 


Digit(8) 


Octet 11 


Digit(8) 




APPENDED MBC #3 



APPENDED DATA UDTF=01002 




7|6 |5|4|3 |2| 1 |0 


Oc-tet 


Digit(8) 


Octet 1 


Digit(8) 


Oc-tet 2 


Digit(8) 


Oc-tet 3 


Digit(8) 


Oc-tet 4 


Digit(8) 


Oc-tet 5 


Digit(8) 


Oc-tet 6 


Digit(8) 


Oc-tet 7 


Digit(8) 


Oc-tet 8 


Digit(8) 


Oc-tet 9 


Digit(8) 




APPENDED MBC #4 



Figure B.18: Unified Data Transport Format (8 bit character) 35 character symbols 

to 46 character symbols 

B.3.6 Appended Data NMEA (lEC 61 1 62-1 ) format 

Appended data is with essential data elements for NMEA formatted (lEC 61162-1 [8]) coordinates. Up to two appended 
data UDTs may be concatenated with a UDT appended data header to form a multi-block UDT PDU. The information 
elements are described in table B.6. 



APPENDED DATA UDTF=010l2 




7 


6 


5 


4 


3 1 2 1 1 |0 


Octet 


C 


NS 


EW 


Q 


SPEED(7)— 


Octet 1 


- 


NDEe(7)— 


Octet 2 


1 NMIN(6) 


Octet 3 


NMINF(14)— 


Octet 4 






___ 




Octet 5 


— EDEe(8) 


- 


Octet 6 


-EMINmm(6) | 


Octet 7 


— EMINF(14) — 


Octet 8 


1 UTChh(5) 1 - 


Octet 9 


UTCmm(6) |UTCss(6)- 


Oc-tet 10 


1 SPARE(5) 


Octet 11 


SPARE(8) 




APPENDED MBC #1 



APPENDED DATA UDTF=010l2 




7|6|5|4|3|2| 1 |0 


Octet 


SPARE(80) 


Octet 1 


Octet 2 


Octet 3 


Octet 4 


Octet 5 


Octet 6 


Octet 7 


Octet 8 


Octet 9 



APPENDED MBC #2 



Figure B.19: Appended Data Short NMEA format 
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APPENDED DATA UDTF=010l2 




^ 


6 


5 


4 


3 1 2 1 1 1 


Octet 


c 


NS 


EW 


Q 


SPEED(7)— 


Octet 1 


- 


NDEe(7)— 


Octet 2 


1 NMIN(6) 


Octet 3 


NMINF(14)— 


Octet 4 










Octet 5 


— EDEe(8) ~ 


Octet 6 


--EMINmm(6) | 


Octet 7 


— -EMINF(14)— - 


Octet 8 


1 UTChh(5) 1 - 


Octet 9 


UTCmm(6) |UTCss(6)- 


Octet 10 


1 SPARE(5) 


Octet 11 


SPARE(8) 




APPENDED MBC #1 



APPENDED DATA UDTF=010l2 




7|6|5|4|3 


2 1 1 1 


Octet 


UTChh(5) 


__. 


Octet 1 


UTCmm(6)| UTCss(6)— 


Octet 2 


:J 




Octet 3 






Octet 4 


SPARE(63) 


Octet 5 


Octet 6 


Octet 7 


Octet 8 


Octet 9 







APPENDED MBC #2 



Figure B.20: Appended Data Long NMEA format 
Table B.6: Appended Data NMEA Elements 



Alias 


Length 


Value 


Description 


C 


1 





Data is not encrypted 


1 


Data is encrypted 


NS 


1 





Latitude Direction - South 


1 


Latitude Direction - North 


EW 


1 





Longitude Direction - West 


1 


Longitude Direction - East 


Q 


1 





GPS Quality Indicator - No fix 


1 


GPS Quality Indicator - Fix Valid 


SPEED 


7 




Speed in knots (0-126) 


NDEG 


7 




Latitude Degrees (00-89) 


NMINmm 


6 




Latitude Minutes (00-59) 


NMINF 


14 




Latitude Fractions of minutes (0000-9999) 


EDEG 


8 




Longitude Degrees (000-179) 


EMINmm 


6 




Longitude Minutes (00-59) 


EMINF 


14 




Longitude Fractions of minutes (0000-9999) 


RSVD 


6 






UTChh 


5 




UTC time hours (00-23) 


UTCmm 


6 




UTC time minutes (00-59) 


UTCss 


6 




UTC time seconds (00-59) 



B.3.7 UDTDMR IP format 

The UDT IP format is illustrated in figures B.21 and B.22. 



APPENDED DATA UDTF=01102 




7 


6|5|4|3|2| 1 |0 


Oc-tetO 


IPV4 ADDRESS(32) 


Octet 1 


OclBt2 


OclBt3 


OclBt4 


RSVD(48) 


OclBt5 


OclBt6 


OclBt7 


OclBt8 


OclBt9 



APPENDED MBC #1 



Figure B.21 : Appended Data IPV4 format 
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APPENDED DATA UDTF=01102 




7|6|5|4|3|2|1|0 


Octet 


IPV6 ADDRESS(96) — 


Octet 1 


Octet 2 


Octet 3 


Octet 4 


Octet 5 


Octet 6 


Octet 7 


Octets 


Octet 9 


Octet 10 


Octet 11 




APPENDED MBC #1 



APPENDED DATA UDTF=01102 




7|6|5|4|3|2|1|0 


Octet 


IPV6 ADDRESS(32) — 


Octet 1 


Octet 2 


Octet 3 


Octet 4 


RSVD(48) 


Octet 5 


Octet 6 


Octet 7 


Octet 8 


Octet 9 




APPENDED MBC #2 



Figure B.22: Appended Data IPV6 format 



B.3.8 Appended Data Unicode 1 6 bit Character Format 

Appended data is coded Unicode (lEC 61162-1 [8]) 16 bit character format. Up to four appended data UDTs may be 
concatenated with UDT appended data header to form a multi-block UDT PDU. Up to 23 Unicode characters may be 
transported. The Pad Nibble information element in the UDT header specifies the number of 4 bit nibbles (1 1 1 12) that 
have been padded to the Unicode Characters to completely fill a block. 

The number of user ISO 7 bit symbols, and the corresponding value of UAB and Pad Nibble is given by table B.7. 

Table B.7: Relationship of 16 bit Unicode Character symbols, 
UAB and Pad Nibble information elements 



User 
Character 
Symbols 


UAB 


Pad Nibble 


1 





16 


2 





12 


3 





8 


4 





4 


5 








6 


1 


20 


7 


1 


16 


8 


1 


12 



User 
Character 
Symbols 


UAB 


Pad Nibble 


9 


1 


8 


10 


1 


4 


11 


1 





12 


2 


20 


13 


2 


16 


14 


2 


12 


15 


2 


8 


16 


2 


4 



User 
Character 
Symbols 


UAB 


Pad Nibble 


17 


2 





18 


3 


20 


19 


3 


16 


20 


3 


12 


21 


3 


8 


22 


3 


4 


23 


3 












APPENDED DATA UDTF=011l2 




7|6|5|4|3|2|1|0 


Octet 


Character Encocling(16) 


Octet 1 


Octet 2 


Character Encocling(16) 


Octets 


Octet 4 


Character Encocling(16) 


Octets 


Octet 6 


Character Encocling(16) 


Octet/ 


Octets 


Character Encocling(16) 


Octet 9 



APPENDED MBC #1 



Figure B.23: Unified Data Transport Format (16 bit character) 1 character symbol 

to 5 character symbols 
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APPENtJEt) DATA Ut)TF=011l2 




7|6|5|4|3|2|1|0 


Octet 


Character Encocling(16) 


Octet 1 


Octet 2 


Character Encocling(16) 


Octet 3 


Octet 4 


Character Encocling(16) 


Octet 5 


Octet 6 


Character Encocling(16) 


Octet 7 


Octet 8 


Character Encocling(16) 


Octet 9 


Octet 10 


Character Encocling(16) 


Octet 11 




APPENDED MBC #1 



APPENDED DATA UDTF=011l2 




7|6|5|4|3|2|1|0 


Octet 


Character Encocling(16) 


Octet 1 


Octet 2 


Character Encocling(16) 


Octet 3 


Octet 4 


Character Encocling(16) 


Octet 5 


Octet 6 


Character Encocling(16) 


Octet 7 


Octet 8 


Character Encocling(16) 


Octet 9 




APPENDED MBC #2 



Figure B.24: Unified Data Transport Format (16 bit character) 6 cliaracter symbols 

to 11 cliaracter symbols 



APPENDED DATA UDTF=011l2 




7|6|5|4|3|2|1|0 


Octet 


Character Encocling(16) 


Octet 1 


Octet 2 


Character Encocling(16) 


Octet 3 


Octet 4 


Character Encocling(16) 


Octet 5 


Octet 6 


Character Encocling(16) 


Octet 7 


Octet 8 


Character Encocling(16) 


Octet 9 


Octet 10 


Character Encocling(16) 


Octet 11 




APPENDED MBC #1 



APPENDED DATA UDTF=011l2 




7|6|5|4|3|2|1|0 


Octet 


Character Encocling(16) 


Octet 1 


Octet 2 


Character Encocling(16) 


Octet 3 


Octet 4 


Character Encocling(16) 


Octet 5 


Octet 6 


Character Encocling(16) 


Octet 7 


Octet 8 


Character Encocling(16) 


Octet 9 


Octet 10 


Character Encocling(16) 


Octet 11 




APPENDED MBC #2 



APPENDED DATA UDTF=011l2 




7|6|5|4|3|2|1|0 


Octet 


Character Encocling(16) 


Octet 1 


Octet 2 


Character Encocling(16) 


Octet 3 


Octet 4 


Character Encocling(16) 


Octet 5 


Octet 6 


Character Encocling(16) 


Octet 7 


Octet 8 


Character Encocling(16) 


Octet 9 




APPENDED MBC #3 



Figure B.25: Unified Data Transport Format (8 bit character) 12 character symbols 

to 17 character symbols 



APPENDED DATA UDTF=011l2 




7|6|5|4|3|2|1|0 


Octet 


Character Encoding(16) 


Octet 1 


Octet 2 


Character Encoding(16) 


Octet 3 


Octet 4 


Character Encoding(16) 


Octet 5 


Octet 6 


Character Encoding(16) 


Octet 7 


Octet 8 


Character Encoding(16) 


Octet 9 


Octet 10 


Character Encoding(16) 


Octet 11 




APPENDED MBC #1 



APPENDED DATA UDTF=011l2 




7|6|5|4|3|2|1|0 


Octet 


Character Encoding(16) 


Octet 1 


Octet 2 


Character Encoding(16) 


Octet 3 


Octet 4 


Character Encoding(16) 


Octet 5 


Octet 6 


Character Encoding(16) 


Octet 7 


Octet 8 


Character Encoding(16) 


Octet 9 


Octet 10 


Character Encoding(16) 


Octet 11 




APPENDED MBC #2 



APPENDED DATA UDTF=011l2 




7|6|5|4|3|2|1|0 


Octet 


Character Encoding(16) 


Octet 1 


Octet 2 


Character Encoding(16) 


Octet 3 


Octet 4 


Character Encoding(16) 


Octet 5 


Octet 6 


Character Encoding(16) 


Octet 7 


Octet 8 


Character Encoding(16) 


Octet 9 


Octet 10 


Character Encoding(16) 


Octet 11 




APPENDED MBC #3 



APPENDED DATA UDTF=011l2 




7|6|5|4|3|2|1|0 


Octet 


Character Encoding(16) 


Octet 1 


Octet 2 


Character Encoding(16) 


Octet 3 


Octet 4 


Character Encoding(16) 


Octet 5 


Octet 6 


Character Encoding(16) 


Octet 7 


Octet 8 


Character Encoding(16) 


Octet 9 




APPENDED MBC #4 



Figure B.26: Unified Data Transport Format (8 bit character) 18 character symbols 

to 23 character symbols 
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Annex C (informative): 
Physical Channel Plan 

C.1 Transmission and Reception 

C.1.1 RF carriers 

C.1 .1 .1 Nominal carriers frequencies 

The nominal carrier frequencies for DMR may be allocated in any of the frequency bands in the range 50 MHz to 
999 MHz. Upper layers of the protocol stack define a single logical channel number that equates to a transmitter and 
receiver frequencies in the range 1 to 4 094. Since the DMR Standard supports re-assigning of existing analogue 
channels, flexibility may be provided where prescribed channel plans are suitable. 

DMR may therefore support: 

• a number of fixed channel plans where the MS transmit frequency, the split between transmit and receive, the 
channel separation and if the receiver is high or low relative to the transmitter; 

• a flexible channel plan whereby each logical channel may represent a transmitter and receiver frequency pair; 

• a broadcast PDU that enables the TSCC to announce a logical / physical transmitter and receiver relationship; 

• an extended channel grant PDU that specifies the physical transmitter and receiver frequencies. 

The higher DMR layers only have the logical CHAN SDU to define the physical frequencies. The additional parameters 
(type of channel plan, Tx/Rx separation, etc.) exist in the physical layer only and are programmed during 
personalization or manufacture of the equipment. A National Administration may mandate certain limitations on 
particular frequencies (such as transmitter power). 

C.1 .1 .2 Fixed Channel Plan 

The nominal MS Tx frequency fjyj^ j^ corresponds to its logical carrier number, CHAN, which is defined as: 
^MS Tx " ^^ transmit frequency (MHz) 

^base " ^^^ lowest frequency in a particular band relating to logical CHAN=1 (MHz) 
^separation " ^^^ frequency separation between two adjacent channels (kHz) 

^duplexsplit - The difference between MS Tx and MS Rx [for clarity MS Tx minus MS Rx] (±MHz) 
fMS_Tx = fbase + ((CHAN-1) X (fseparation/1 OOo)) ^Hz 
^MS.Rx = ^MS.Tx - ^duplexsplit ^^^ 
^duplexsplit - ^ MHz to 50 MHz in 2,5 kHz steps 
fseparation- Definition 
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Table C.I : Frequency Separation 



SDU Code (SEP) 


Separation (l<Hz) 


OOOO2 


5 


0001 2 


6,25 


001 O2 


10 


00112 


12,5 


01002 


15 


01012 


20 


01102 


25 


01112 


30 


1XXX2 


reserved 



fgplj^ - The difference between MS Tx and MS Rx [for clarity MS Tx minus MS Rx] (±MHz) 

Table C.2: Frequency Split high/low 



SDU Code (TXRX SPLIT) 




O2 


MS Tx is high of IVIS Rx 


I2 


IVIS Tx is low of IVIS Rx 



fduplexsplit - Definition 



Table C.3: Frequency Split 



SDU Code (DUPLEX SPLIT) 


Duplex Split (kHz) 


000 0000 0000 OOOO2 





000 0000 0000 0001 2 


2,5 






000 0111 0011 OOOO2 


4 600 (4,6 MHz) 






0001100100000002 


8 000 (8 MHz) 






000 1111 1010000O2 


10 000 (10 MHz) 






10001100101 OOOO2 


45 000 (45 MHz) 



^base " ^^^^ Definition 



Table C.4: Band Definition 



SDU Code (BAND) 


fbaseMHz 


000 0011 2 


30 


00001002 


40 


00001012 


50 


00001102 


60 


00001112 


70 






01011002 


450 






101 OOOO2 


800 


11001002 


1 000 
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chan - Logical Channel Numbers 



Table C.5: Logical Channel Numbers 



Channel Number 


SDU Code (CHAN) 


Colour Code (see note) 


1 


0000 0000 0001 2 


Value 








4 094 


1111 1111 11102 


Value 


NOTE: The default colour code =00002- 



C.1 .1 .3 Flexible Channel Plan 

Each logical channel number has the transmitter and receiver frequency defined. 

Table C.6: Flexible Channel Plan 



Channel Number 


SDU Code (CHAN) 


Transmitter 
Frequency 


Receiver 
Frequency 


Colour Code 
(see note) 


1 


0000 0000 0001 2 






Value 












4 094 


1111 1111 11102 






Value 


NOTE: The default colour code =00002- 



c.1 .1 .4 Determination of Transmitter and Receiver frequency from 
CdefParms 

The MS absolute transmitter and receiver frequency is defined in 125 Hz steps as illustrated in table C.7. 

Table 0.7: Absolute Transmitter and Receiver SDUs 



ALIAS 


SDU Code 


Transmitter/Receiver Frequency 


TXMHz 
RXMHz 


000 0011 001 O2 


50 MHz 


111 110011112 


999 MHz 


TXKHz 
RXKHz 


0000 0000 OOOO2 


OHz 


0000 0000 0001 2 


+125 Hz 


0000 0000 001 O2 


+250 Hz 


1 1111 0011 IIII2 


+999 875 Hz 



The absolute transmitter frequency (MHz) = TXMHz + (TXKHz x 125)/1 000. 
The absolute receiver frequency (MHz) = RXMHz + (RXKHz x 125)/1 000. 
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Annex D (informative): 

Control Channel Hunting Procedures 

D.1 Introduction 

In order to locate a valid TSCC, the MS hunts through a list candidate physical channels until an appropriate TSCC is 
selected and confirmed. This TSCC hunting may involve a variety of hunting sequences depending on the 
circumstances of the hunt. This annex shows a framework for MS hunting strategy. 

Since two logical TDMA channels occupy one physical channel, the MS can appraise both logical channels 
concurrently when sampling a physical channel. The MS may use information from the CACH or PDUs that contain a 
C_SYScode information element to use for verification tests specified in clause 6.3.2.2.1. 

The Control Channel Hunting Procedure stages are: 

a) The "resuming a TSCC hunt channel" allows an MS, after a period of activity on a payload physical channel, 
to resume the TSCC on which it was last confirmed prior to the payload Channel Grant PDU. 

b) The "commanded TSCC hunt channel" is employed when a MS is directed on the TSCC to a particular TSCC 
(from a C_MOVE or P_CLEAR PDU) or seeks to regain a TSCC after a period of inactivity on the selected 
network (due to being switched off or a user-initiated change of selected network when details of the last 
confirmed TSCC number have been stored by the MS in non- volatile storage). 

"Short Hunt Sequence": A hunting sequence, which samples all physical channel numbers likely to be employed as 
TSCCs by the selected network. A list of Nmax_Ch likely logical candidate physical channel numbers is held in MS 
fixed non- volatile storage for the selected network. The MS should have the storage for up to 64 values of the logical 
physical channel number information element defining the extent of the "short hunt sequence". Unused storage 
locations are marked such that the MS may ignore them. Particular Physical channel numbers may be stored in the list 
numerous times to provide a bias to that particular TSCC. 

c) "Comprehensive Hunt Sequence". A hunting sequence, that samples all possible physical channel numbers in 
use by the network. This hunting sequence provides a contingency to allow TSCCs to be acquired even when 
physical channel numbers not normally employed for this purpose are in use. The "comprehensive hunt 
sequence" may be temporarily suspended to sample likely physical channels or repeat a "short hunt sequence". 
The lowest Low_Comp_Ch and highest High_Comp_Ch is held in the MS fixed non-volatile storage. 

NOTE 1: The "Comprehensive Hunt Sequence" may be suppressed by network personalization. 

When carrying out a "resuming a TSCC hunt channel" or "commanded TSCC hunt channel" the hunting procedure is 
considered complete when the MS has tuned directly to the physical channel and has carried out the appropriate 
verification and confirmation procedures specified in clause 6.3. 
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Figure D.1: Physical Channel Hunting 

Figure D.l shows a possible implementation of the "Short Hunt Sequence" and "Comprehensive Hunt" Sequence. If the 
MS needs to search for an appropriate TSCC, this process searches the most likely physical channel candidates first. 
This example of a possible implementation carries out the short hunt twice, the first loop being exercised looking for a 
TSCC whose signal strength exceeds a defined value (L_SigShort). 

A hunting sequence may be considered complete when either: 

a) a physical channel is found that satisfies the TSCC verification and confirmation tests specified in clause 6.3. 
(The hunting procedure was successful); 

b) all physical channel numbers within the scope of the hunting sequence have been tested without a physical 
channel being found which satisfies the TSCC confirmation tests specified in clause 6.3 (the hunting sequence 
failed). 

The MS carries out the hunting procedure in the order described in this clause. If a hunting sequence is unsuccessfully 
completed, then the MS starts the next hunting sequence. The final hunting sequence is the "comprehensive hunt 
sequence". If this hunting sequence cannot be completed, the MS stays in this hunting sequence until a TSCC is 
confirmed. However, the foregoing provisions of this clause may be relaxed in the following circumstances: 

• the "comprehensive hunt sequence" may be suppressed by MS personalization for a network; 

• a MS in a "comprehensive hunt sequence" may elect to perform complete hunting sequences of any other type, 
returning to the "comprehensive hunt sequence" in the event of failure to confirm an appropriate TSCC; 

• a MS may elect to sample any physical channel that may satisfy the TSCC verification and confirmation tests 
specified in clause 6.3. 

Where a hunting stage involves more than one physical channel the order in which physical channels are sampled is not 
specified. However, in order to guard against bias towards certain physical channels, MSs should ensure randomness in 
the order in which physical channels are sampled by one of the following: 

• hunting physical channel numbers sequentially (e.g. from lowest to highest number) but beginning the hunting 
stage at a random position in the sequence of physical channel numbers; 

• hunting physical channel numbers in a random fashion. 
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The procedures defined in the present document are intended to provide a comprehensive range of methods that may be 
used as a basis for the design of MSs. 

NOTE 2: The specified mechanism is a framework for MSs. The use of additional or differing procedures is not 
prohibited provided that they satisfy the verification and confirmation procedures defined in the present 
document. 

EXAMPLE: A MS locating a physical channel which satisfies the TSCC confirmation tests specified in 

clause 6.3 may continue the hunt in anticipation that an alternative TSCC may be found with a 
higher received signal quality or level. Also, MSs need not limit the hunting procedures to the 
receiver sensitivity threshold levels specified and may conduct additional hunts at other levels. 



D.1 .1 Resuming a TSCC hunt channel 



When "resuming a TSCC hunt channel" the MS retunes to the logical physical channel number of the TSCC on which it 
was last confirmed. The MS should be capable of receiving on the TSCC outbound channel, which it is resuming within 
two TDM A-frames of the following instants: 

a) the end of any P_CLEAR PDU, which requires the MS to cease activity on the payload channel to which it is 
currently tuned; 

b) the end of the last payload disconnect PDU P_MAINT (Maint_Kind=DISCON) sent by the MS on a payload 
channel; 

c) the end of any call authorization check PDU (P_AUTH) received on a payload channel where the MS address 
information element in the P_AUTH PDU does NOT match one of the addresses from the Channel Grant PDU 
that directed the MS to the payload channel; 

d) the operation of the any user initiated "call end request" by the user during a talkgroup call when the MS was 
not the call originator of the call. 

Before confirming the TSCC the MS should verify any C_SYScode received on the channel in accordance with the 
procedures of clause 6.3.2.2.1. In the event of the C_SYScode fails the verification procedures, the hunting sequence is 
considered unsuccessfully completed and the MS enters the "short hunt sequence". 

D.1 .2 Commanded TSCC hunt channel 

D.1 .2.1 Conditions to enter a Commanded TSCC hunt 

A "single channel hunt" applies when the MS is directed to a TSCC other than the one on which it was last confirmed, 
or when it is switched on whilst still retaining valid network information from previous activity on the selected network, 
or the user initiates a change of selected network and the MS still retains valid information of previous activity on the 
new selected network. The MS should be able to receive the nominated physical channel within 3 TDMA slots of the 
following instants: 

a) the end of any valid C_MOVE PDU that is applicable to the MS; 

b) the MS being switched on, provided that the unit holds a valid record of the channel number on which the MS 
was most recently confirmed; 

c) a change of selected network being initiated by the user, provided that the MS holds a valid record of the 
channel number on which the MS was most recently confirmed on the new selected network. 
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D.1 .2.2 Nominated Channel for the Single Channel Hunt 

The nominated channel is: 

a) the logical physical channel number indicated in the CONT information element of the P_CLEAR PDU; or 

b) the channel number indicated in the CONT information element the C_MOVE PDU; or 

c) the channel number held in the MSs read/write storage as the TSCC on which the unit was most recently 
confirmed on the selected network. 

The MS does not make any transmissions on a TSCC until it has confirmed the channel in accordance with the 
procedure specified in clause 6.3. In the event of a failure of the TSCC to meet the channel confirmation criteria the 
hunting sequence is considered unsuccessfully completed. Upon unsuccessful completion of the "commanded TSCC 
hunt channel" the MS enters the "short hunt sequence". 



D.1 .2.3 Short Hunt Sequence 



A "Short Hunt Sequence" samples all physical channels most likely to be employed as TSCCs by the selected network. 
There are many strategies that may be employed but all strategies search from a shortlist of candidates as follows: 

a) A list of likely physical channels will be specified by an external agency stored in MS fixed non- volatile 
storage. 

b) The MS may modify the scope of the shortlist of physical channels from information broadcast from the 
network and held in its non- volatile storage as follows: 

1) by adding to the compass of the hunting sequence channel numbers received in C_BCAST 
(AnnounceAVithdraw) PDU from the selected network; 

2) by removing from the compass of the hunting sequence channel numbers received in C_BCAST 
(AnnounceAVithdraw) PDUs from the selected network. 

One strategy illustrated in figure D.1 entails hunting the list of physical channel numbers sequentially (e.g. from the 
randomly chosen list position to the highest then circling to the lowest list position) but beginning the hunting stage at a 
random position in the sequence of physical channel numbers. The shortlist is sampled twice, the first loop being 
exercised looking for a TSCC whose signal strength exceeds a defined value (L_Short). 

Another possible strategy entails hunting the complete shortlist of physical channel numbers sequentially (e.g. from 
lowest list position to highest list position) recording the signal strength and/or BER. After sampling all channels in the 
list the MS chooses the most appropriate TSCC. 

D.1 .2.3.1 Conditions to enter a Short Channel Hunt 

A MS enters the "short hunt sequence": 

a) immediately after switch-on, provided that the MS holds no valid information of previous activity on the 
selected network; 

b) when the user indicates a change of selected network, provided that the MS holds no valid information of 
previous activity on the selected network. 

The MS may enter the "short hunt sequence" at any time during the "comprehensive hunt sequence", at the MSs 
discretion. 

The MS should not make any transmissions on a TSCC located during the "short hunt sequence" until it has verified 
and confirmed the channel in accordance with the procedures specified in clause 6.3. 

Upon unsuccessful completion of the "short hunt sequence" the MS enters the "comprehensive hunt sequence", except 
when the "comprehensive hunt sequence" has been suppressed by MS personalization for a network. 
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D.1 .2.4 Comprehensive Hunt Sequence 

The "comprehensive hunt sequence" includes every channel within the range set by the lowest and highest channel 
numbers set by the network personalization, held in the MSs fixed non- volatile storage. 

D.1 .2.4.1 Conditions to enter a Comprehensive Channel Hunt 

A MS enters the "comprehensive hunt sequence" when a "short hunt sequence" has been unsuccessfully completed. 

A MS may repeat the "comprehensive hunt stage" until such a time as a physical channel which satisfies the TSCC 
confirmation tests specified in clause 6.3 is found. 

The MS does not make any transmissions on a TSCC located during the "comprehensive hunt sequence" until it has 
confirmed the channel in accordance with the procedures specified in clause 6.3. 

At any time during the "comprehensive hunt sequence" a MS may undertake a "short hunt sequence", or sample any 
physical channels that the MS is able to determine may be successful, returning to the "comprehensive hunt sequence" 
in the event that these choices is unsuccessful. 

It is possible to suppress the "comprehensive hunt sequence" by MS network personalization. In this case the MS 
remains in the "short hunt sequence" with the acquisition threshold set to a level L_Squelch until such time as a channel 
which satisfies the TSCC confirmation tests specified in clause 6.3. 

D.1 .2.5 Receiver Sensitivity During Control Channel Acquisition 

The MS should not attempt to become active on any physical channel for which the received signal level (or signal 
quality) is less than the specified acquisition threshold. 

The acquisition threshold L_SHort is set to a signal level within the range L_Upper_SHort to L_Lower_SHort at the 
input of the receiver (or an equivalent if the receiver measures signal quality). 

L_Squelch is set at a level determined by the MS manufacturer which enables unsuitable physical channels to be 
rejected on which the received signal is inadequate for a suitable grade of service (or an equivalent if the receiver 
measures signal quality). 

NOTE: The MS may be unable to determine the received signal level but may use other methods such as bit error 
measurements to determine the signal quality. 
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Annex E (informative): 

Use of MSC and SDL diagrams 

E.1 Introduction 

The present document makes use of SDL and MSC diagrams to complement textual behaviour descriptions in DMR 
Part Trunking Services and Facilities Protocol. 



E.2 Principle 



The MSC and SDL diagrams express the same behaviour (requirement) as defined by the textual description so they 
only complement the textual description in order to provide an alternative perspective on a requirement. The 
development of these diagrams also may also support validation of the textual description, e.g. identifying missing stop 
of a timer when other expected behaviour occurs before timeout. 



E.3 Notation 

The MSC-diagrams make use of the following constructs illustrated in figure E.l. 



Message exchange between 
instances 



Start timer 



_^/ Stop timer 



_^ Timer Expiry 



Figure E.1 : SDL Notation 

1) Message exchange between instances (line with arrow associated with message name and parameters in 
parentheses). 

2) Start timer (horizontal line with hour-glass). 

3) Stop timer, (horizontal line with 'x'). 

4) Timeout (horizontal line with arrow and hour-glass). 

5) The optional inline construct, (rectangle with keyword 'opt' in upper left corner). The meaning of the optional 
inline construct is that the contained behaviour is optional to occur. 

6) The alternative inline construct (rectangle with keyword 'alt' in upper left corner and dotted separation lines). 
The meaning of this construct is that each of the alternatives divided by the dotted line is a possible behaviour 
of which exactly one is to occur for the MSC. 
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In the SDL diagrams only basic process behaviour symbols are used, that is state, input, output, decision, timer start, 
and timer stop symbols. 
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